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System capacities 


Hardware 


This section describes the six primary capacity categories of the Meridian 1 
system: hardware, network traffic, signaling and data link, processor load, 
memory size, and mass storage size. For each category, the units in which the 
capacity is measured are identified. Primary physical and functional elements 
affecting the capacity are detailed, and actions which can be used to engineer 
the capacity are described. An algorithm is given by which capacity impacts 
can be computed. 


The worksheets in “Worksheets” on page 231 implement the algorithms. In 
some cases applications such as call center require detailed engineering. 
These applications are discussed in “Application engineering” on page 135. 








The hardware resources considered in this section include physical capacity, 
power, and heat dissipation. Here, physical capacity is a broad term that is 
used to subsume three specific resources: loops, slots, and I/O devices. An 
overview of the physical configuration provides an explanation for the slot 
constraints. 


Physical configuration overview 


System types 

Option 11 (11E / 11C) The option 11 is a small Meridian PBX, offering the 
advantage of simple installation, maintenance, and administration, while 
retaining the full features of a large system. Option 11 uses XPE hardware to 
maintain compatibility with other Meridian systems. 
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The main difference in architecture of option 11 from larger Meridian 
systems is that it extends the CPU bus to XPE slots, thus eliminating the 
network bus, and limiting the network capacity to 320 timeslots per box. This 
architecture eliminates one level of bit-to-byte and byte-to-bit conversion, 
and also eliminates a phase lock loop circuit to synchronize the DS-30 5 MHz 
timing to the MSL-1 network bus 8 MHz timing. 


The maximum sized option 11 consists of three boxes, a base box, the box 
with daughterboard, and the expansion box. The maximized option 11C has 
a main cabinet with two expansion cabinets. 


Option 11E (not supported in X11 Release 22 or higher) The base box 
comprises the COMBO pack which is a direct replacement for three existing 
option 11 packs: CPU/CONF, TDS/DTR and XTD. 


The COMBO pack consists of CPU, 128k words of Udata, 128k words of 
Pdata, Network Conference, 8 DTR/DTD units, and three SDI ports. The 
COMBO pack also supports an expansion daughterboard to add extra 
switching capacity (10 more DS30X loops for 10 XPE slots) and memory size 
(128k word Udata/Pdata) to the system. 


The expansion box consists of 10 XPE slots. 
A SPORT pack consists of two ESDI/SDI ports and two DCHI/SDI ports. 


Any of PRI, BRA, RAN, XDLC, XUT packs, and Meridian Mail will take 
one XPE slot.The Meridian Mail must be installed in the tenth slot of the base 
box. The system with the daughterboard has a total of 20 slots. With the 
expansion box, it has 30 slots. The first slot is reserved for CPU and service 
functions. The maximum number of total traffic slots in the system is 29. The 
system capacity is reduced when features requiring XPE slots for interface 
are deployed, e.g., AML or Meridian Mail. 


The daughterboard is connected to the base system by a copper cable or an 
optional optics package. The expansion box is connected to the base system 
by a single fiber cable. The expansion daughterboard contains signaling 
channels that are not required for the base system. Packs requiring direct 
access to the CPU bus, such as PRI, are supported in the base box only. 
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The system has a total of 960 timeslots when daughterboard and expansion 

box are equipped. The network is non-blocking. The 960 timeslots are split 

up into 30 DS30X loops, each with 32 timeslots. The system backplanes in 

all boxes can interface with 24 ports from each XPE slot. This assures that at 
least one timeslot is available to every port. 


The basic building blocks in the system are the XPE hardware of the 16-port 
line card (XDLC) and the 8-port trunk card (XUT) or 24/30-port PRIs. 


A simplified block diagram of the base box and expansion boxes is shown in 
Figure 6 and as follows: 


Legend: 

COMBO: Combination of CPU/CONF and TDS/DTR packs 
SPORT: Small System I/O Ports (2 ESDI/SDI and 2 DCHI/SDI) 
XDLC: Extended Digital Line Card 


XTD: Extended DTD and DTR (dial tone detector and digitone receiver), an 
international pack 


XUT: Extended Universal Trunk Card 


XPE: Extended Peripheral Equipment, the slot can be used for XDLC or XUT 
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Figure 6 
Simplified block diagram of the base box 


Base Box 


10 DS-30X 


10 DS-30X 


Daughterboard 
553-0045 
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Option 11C The Option 11C is an upgrade of the Option 11 to a Motorola 
68040 CPU with VxWorks operating system. This affects the real time 
performance and the memory architecture. Its real time capacity is about 8 
times that of the Option 11, but its physical capacity is still the same. (In 
actual practice it is greater for some configurations, now that real time is no 
longer a constraint.) 


The memory architecture of the 11C is most like that of the Option 81 
equipped with the NT9D19 call processor. Program and data are stored in 
physically separate memory components - flash EPROM and DRAM, 
respectively. DRAM is presently (Release 23) one 8 Mb SIMM in the single 
DRAM slot, which can be replaced with a 16Mb or 32Mb SIMM. EPROM is 
on a daughterboard which allows 24Mb program storage. This can be 
increased by adding a “babyboard” whose capacity can grow in 8Mb 
increments. Residing on the EPROM daughterboard is also the 8Mb of disk 
emulator ROM. The plan for increasing memory capacity on these systems 
has yet to be fully worked out. 


For a detailed description of the hardware architecture of the option 11C, see 
the overview Option 11C, General Information and Planning Handbook 
(553-3021-200). 


Option 21 (not supported in X11 Release 22 or higher) The option 21 is 
a single group, single CPU system with limited card slots for common 
equipment. In the NT8D11 CE/PE module, there are seven network card slots 
(slots 4 to 10). The number 10 slot is always equipped with the NT8D18 
Network/DTR card, which provides DTR function and one superloop (four 
loops) to the IPE cards in the same module. 


For practical applications, one card slot is always equipped with TDS/CON 
(Tone and Digit Switch/Conference) card. The remaining 5 slots can equip 
5 XNET cards or 5 Enhanced Network (ENET) cards. With 6 XNET cards 
(including the Network/DTR card), and one TDS/CON card, the system can 
have a maximum of 26 loops. 


Alternatively, when all 5 card slots are equipped with ENET cards plus the 
TDS/CON card, they support 12 loops. Adding 4 IPE loops associated with 
the NT8D18 Network DTR card, the system can equip a maximum of 

16 loops (but with no slot for Enhanced Serial Data Interface [ESDI], 
D-Channel Interface [DCHI], and so on). 
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Option 61 (not supported in X11 Release 22 or higher) An option 61 
consists of two CPU/Network modules and up to five IPE and UEM 
modules.The NT6D39 CPU/Network card has eight card slots for Network 
and I/O cards. In addition, there is a fixed slot for the Clock Controller and 
the serial data interface (SDI) which is not included in the eight slots. It is 
assumed that one TDS/CON card is equipped per CPU/Network module. 
Without considering applications, 14 card slots can support 28 enhanced 
peripheral equipment (EPE) or IPE traffic loops. 


The option 61 has a maximum of 28 traffic loops (32, if TDS/CON loops are 
counted); it appears that as long as some IPEs are used, the system will run 
out of loops before it will run out of card slots. 


Option 71/81 (Option 71 not supported in X11 Release 22 or higher) 
The option 71/81 comprises a maximum of 10 NT8D35 Network Modules 
when the system is fully equipped with 5 groups. Each network module has 
8 slots for network cards. Therefore, a maximum of 80 slots or 160 loops is 
allowed in the system. As a general practice, two TDS/CON cards are 
assigned to each group, so the number of loops usable for general traffic 
becomes 28. The system capacity becomes 70 slots or 140 loops. This should 
be the upper limit for general applications. 


Other than a potential space limitation in a switch room, the number of 
NT8D35 modules used for providing power and space can be as many as 
needed. Therefore, the capacity constraint in an option 71 or 81 is the number 
of loops, not card slots. 


For a more detailed description of system types and modules, see Meridian 1 
system overview (553-3001-100). 


Physical capacity 


553-3001-149 


Resource constraints 

The physical constraints consist primarily of loop card slot limitations at the 
network shelf. From practical experience, running out of PE shelves is rare, 
particularly for Call Center applications. 
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Option 11 (11E/11C) 

The base box in option 11 has 10 XPE slots with 9 available for general use. 
The expansion daughterboard provides 10 XPE slots, and the expansion box 
has 10 additional XPE slots. The number of available card slots is the limit of 
the physical capacity of an option 11. 


For the purpose of card slot calculation, an agent supervisor set is treated like 
an agent set, however, its call intensity is reduced for real time calculations. 


1 


Agent Sets and Analog Trunks 


When the system serves as a Call Center, it will most likely be equipped 
with more trunks than agent sets (lines). A practical trunk to agent ratio 
is within the range of 1.1 tol.5. The reason for having a higher number 
of trunks is that there are calls in the queue which engage trunk circuits 
but not ACD agents until they are served. In addition, in an NACD 
application, the overflowed calls continue to occupy trunks without the 
service of agents at the source node. 


An XDLC card can accommodate 16 agent sets, and an XUT analog card 
can serve 8 trunks. These numbers of ports per card and ratio are used as 
the basis of calculations in this document. Any other cards used which 
different from these numbers will change the equations. Let L= the 
number of lines, agent sets and supervisor sets, T = the number of trunks. 
N, = the number of XPE slots for agent sets and analog trunks. Use the 


following equation to calculate the number of slots required: 


Number of slots for agent sets with analog trunks = N, = [L/16]*+ 
[T/8]*. 

[ ] * means use the next higher integer, or “round-up”. For example, 
[4]*=4 and [3.1]*= 4. 


If N; > 29, the configuration requirement exceeds the capacity of an 
option 11. 
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2 Agent Sets and PRI trunks 


This configuration requires that all PRI cards (NTAKO09-1.5Mb) be 
equipped in the base cabinet from slot 1 through 9. Although Clock 
Controller (NTAK20) and D-channel (NTAK93) cards are needed for 
PRI applications, they are daughter boards used in conjunction with the 
PRI card and therefore, do not take up an XPE slot. We will ignore them 
for the purpose of calculating card slot requirements. 


TDS/DTR functions are provided by the CPU card, they do not require 
any XPE slot. There are a maximum of 29 slots available for a 
combination of PRI cards and XDLC cards for agents.The split of slots 
for trunks and agents should meet the objective of providing a balanced 
trunk/agent traffic. The following equation provides the calculation 
procedure for digital trunks: 


Number of slots for agent sets with digital trunks = N, = [L/16]* + 
[(T+2)/24]*. 


If N; > 29, the configuration requirement exceeds the capacity of an 


option 11. When a back-up D-channel is not needed, the term (T+2) 
in the equation can be replaced by (T+1). 


For an international version PRI, a card has 30 ports instead of 24. 
Since 30B+D is always required (no nB+D), the last term in the 
equation should read [T/30]. 


3 Slots for RAN, MUS, MMail and Applications 


Ports in a trunk card can be configured to provide RAN or MUSic 
service. Except for very special applications, one XUT card is usually 
sufficient for this type of services. We will always assume that one XUT 
is adequate in the following procedure. 


To provide ESDI ports for AML applications, such as CCR or HER, a 
SPORT card is needed. Use the following equation to calculate the 
number of slots required: 


Number of slots for service ports = N3 = 1 (for RAN/MUS) + 1 (for 
Meridian Mail) + 1 (for AML/CCR/HER) 


Since there are 3 SDI ports on the COMBO card (two are used for 
TTYs), we assume that there is no need to add a DCH/SDI card 
(NTAKO2) for additional SDI ports for (MAX or CDR). 
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4 Physical Limit 


The following procedure can be used to calculate Nt, the total number of 
card slots required in the system: 


N,=N, + N3, if agent sets and all analog trunks. 
Ni = N2 + N3, if agent sets and all digital trunks. 


When a system allows a mixed analog and digital trunks, the total 
number of slots can be calculated as follows: 


N, = N; + No+ N3, if agent sets and mixed analog and digital trunks. 


If the total number of card slots (N,) is less than or equal to 9, one 
base cabinet is sufficient to meet the configuration requirement. 


If 29 > N, > 9, the configuration can be met by option 11 with a 
daughterboard and the expansion box. 


If N; > 29, the configuration requirement can not be met by an 
option 11. 
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Option 21, 51, 51C, 61, 61C, 71, 81, 81C 

Loop constraints The maximum number of loops in a network group is 32, 
including service loops. For practical applications, the number of traffic loops 
is usually limited to 28, reserving two loops each for TDS and CONference. 


1 = Non-ACD (non-Automatic Call Distribution) sets and analog trunks 


Non-ACD sets and trunks will be treated differently from ACD 
applications for estimating loop requirements. These circuits are 
equipped in the PE shelf, and do not use slots in the Network shelf, and, 
therefore, will not be included in the Network Module Card Slots 
Calculation. 


If there is any doubt about potentially running out of PE slots for a given 
application (for example, Hotel/Motel environment), going over PE slots 
to check possible card slot limitations may be desired. Since this is a rare 
occurrence, a calculation procedure will not be developed for it. 


For Call Center applications, due to high common channel signalling 
(CCS) on circuits (agents or trunks), there is no need to be concerned 
about physical slot constraints on the PE shelf since real time will be the 
limiting resource. 


The following procedure should be usable for general and Call Center 
applications. 


For EPE ENET loops: 


Number of loops for non-ACD set and trunk traffic = Noe= 


[(No. of sets x 6 + No. of non-ACD trunks x 26)/660]* 
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For IPE XNET loops: 


Number of loops for non-ACD set and trunk traffic = No,= 


[(No. of sets x 6 + No. of non-ACD trunks x 26)/875]* 
and No = Noe + Nox 


The above calculations account for blocking ENET and XNET loops. 


[] * means use the next higher integer, or “round up.” For example, 
[4]* = 4 and [3.1]* = 4. 


To simplify the notation in this document, the “+” at the upper right 
corner of the bracket will be omitted. Therefore, [x] will mean to round 
up x to the next higher integer. 


The default value of 6 CCS per set and 26 CCS per trunk can be replaced 
by actual numbers for a particular site if they are given. Note that the 
default trunk traffic assumed for non-ACD application is lower than that 
of an ACD trunk (28 CCS). The 875 CCS per loop in IPE is derived from 
superloop capacity of 3500 CCS divided by 4 to obtain the average CCS 
per loop. 


When Primary Rate Interface (PRI) trunks are involved in non-ACD 
applications, they should be treated just like ACD PRI trunks and 
included in the calculations for both loop and card slot requirements. 
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2 Agent sets and ACD analog trunks 


When the system serves as a Call Center, it will most likely be equipped 
with more trunks than agent sets (lines). The reason for having a higher 
number of trunks is that there are calls in the queue which engage trunk 
circuits but not ACD agents until being served. In addition, in an NACD 
application, the overflowed calls continue to occupy trunks without the 
service of agents at the source node. However, this trunk-to-agent ratio 
may change if a service requires a long post-call processing time from an 
agent. In that case, CCS per agent should be reduced reflecting the actual 
agent service time which are associated with actual calls to the Meridian 
1 CPU. 


Traffic at agent sets is conservatively assumed to be 33 CCS and 

18.3 (= 33 x 100/180) calls per agent in the busy hour as a default in 
examples. For applications with long post-call processing time, the 
numbers 18 CCS and 10 calls per agent perhaps are appropriate default 
values. 


Based on the standard Meridian 1 engineering rules, a loop can handle 
660 CCS and a superloop can handle 3500 CCS. When an agent is loaded 
to 33 CCS, a loop can equip 20 agents (= 660/33) and a superloop 

106 (= 3500/33); both numbers are less than their respective number of 
time slots (30 for loop, 120 for superloop). Thus, normal network 
engineering rules for Meridian 1 do not apply in a Call Center 
environment, because the “infinite traffic source” assumption in the 
Erlang model is violated. 


The traffic model will be ignored here. Instead the rule of equipping 

30 agents per loop and 120 agents per superloop for a nonblocking 
connection will be used. A superloop was created to take advantage of 
the traffic theory that a bigger server group is more efficient than a 
smaller one. This is no longer true in a nonblocking application, so any 
superloop can be replaced by four loops without capacity impact. If IPE 
is desired, divide the required number of loops by four to get the 
equivalent number of superloops (except for a DTI/PRI loop which has 
to be an EPE loop). 


For loop requirement calculations, an agent supervisor set is treated like 
an agent set; however, its call intensity is reduced for real time 
calculations. 
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The following is the calculation procedure for loop requirements. Let the 
number of agent sets be L, the number of supervisor sets be L}, the 


number of ACD analog trunks be T,, and the number of Recorded 
Announcement (RAN) trunks be T,: 


Number of nonblocking loops for agent sets, supervisor sets and 
ACD analog trunks = N} = [(L; + L, + T, + T,)/30] 


DTI/PRI trunks 


At an average of 28 CCS per trunk, a loop of 660 CCS can equip 
23 (=660/28) trunks. It is more practical to equip 24 trunks per PRI/DTI 
loop as a rule rather than doing traffic calculations. Let Tg be the number 


of DTI trunks and Tp be the number of PRI trunks. 

The equations for trunk loop calculation are as follows: 
Number of loops for DTI trunks, Nag = [Tg/24]. 
Number of loops for PRI trunks, Nop = [Tp + 2)/24]. 
Number of loops for digital trunks, Np = Naa + Nop. 


When a back-up D-channel is not needed, the term (Tp + 2) in the 
equation for PRI trunks can be replaced by (T, + 1). 


When the number of analog trunks is small (say, 15 or less), it may be 
included in the Nọ calculation to save loop and slot requirements. 


Techniques for reducing the number of card slots required will be 
illustrated in engineering examples with small systems where physical 
slots are scarce. 


For the international version of PRI, 24 ports should be replaced by 30 in 
the above calculations. The rest of the engineering procedure is the same. 
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4 


Loops for Music (MUS) and Meridian Mail (MM) applications 


Music in the Meridian 1 is provided by broadcasting a music source to a 
conference loop. Therefore, a maximum of 30 users can listen to music 
at one time, which is sufficient for most applications. If not, an additional 
conference loop must be provided for each additional 30 simultaneous 
music users. 


Meridian Mail ports are interfaced with a loop to provide voice channels 
for messaging. Each set of 24 ports in the MM is interfaced with one 
loop. The conference loop connects to one half of the TDS/CON card. 
The second conference loop, if needed, will take another card and card 
slot, because it cannot be separated from the TDS loop. 


The network to interface MM must be an ENET. The MM Module takes 
up a whole shelf, normally underneath the CE/PE or CPU module. 
Therefore, it does not impact the available card slots in the Network 
Module (other than requiring an ENET loop for providing voice 
channels). 


Calculation procedure: 
N31 = [Music ports/30] 
N32 = [MM ports for MM or MIVR or HEVP/24] 
Number of loops for applications, N3 = N31 + N32 
Physical limits in loops 


The following procedure can be used to calculate N}; , the total number of 
network loops required in the system: 


Ny =N, +No4+N3. 


Conference loops and TDS loops are called service loops. A service loop 
in EPE takes up the space of a dual network loop. The new 
Conference/TDS loop, combining two functions into one card, also takes 
up the same space. 


A Music feature requires a Conference loop, a RAN card or a DTR card, 
each of which takes up a PE slot. In a small system, the service circuit 
will impact the number of card slots available for lines and trunks. The 
capacity impact of these service loops or circuits will be described. 
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Slot constraints A network loop provides the channels connecting line and 
trunk cards in the PE shelf to a Network Card (ENET or XNET) in the 
network shelf. All cards with system functions, such as ENET, XNET, 
TDS/CON, SDI, ESDI, Multi-purpose Serial Data Interface (MSDL), 
Multi-purpose ISDN Signaling Processor (MISP), Clock Controller, are 
required to be equipped in the network shelf. 


With only seven card slots in the NT8D11 CE/PE module for option 21/21E, 
eight card slots in the NT6D39 CPU/Network module for option 61, and eight 
card slots in the NT5D21 Core/Network Module for Option 61C, the 
availability of card slots in the network shelf tends to be the bottleneck for 
Call Center applications on small systems. 


To relieve the slot shortage on the network shelf, a NT8D35 Network Module 
can be used in place of a UEM module (generalized term for any of 
IPE/PE/RPE/Network modules) for options 21/21E and 61. This module 
provides space and power for QPC720 PRI/DTI cards, but it does not have 
loops to support the QPC414 network card or to provide I/O interfaces. A user 
who is not able to upgrade a small system to a larger one may want to consider 
this option to extend the system to its maximum physical size. 


Another function which competes for network card slots is I/O ports for 
applications. I/O ports are needed for MM (Command Status Link [CSL]), 
Customer Controlled Routing/Host Enhanced Routing (CCR/HER) 
(Application Module Link [AML]), MAX (High Speed Link [HSL]) and 
TTY (SDD. 


There is a slight difference in the demand for I/O card slots between 
options 21 and 61 or 61C, since the latter have slots available for I/O in the 
CPU shelf. Besides, if a Clock Controller in the CPU shelf is not needed in an 
option 61 or 61C, its card slot can also be used for an SDI card. 


To avoid complication in the worksheet, these fine points are pointed out here 
for the user to consider; however, they will not be included as alternatives in 
the card slot worksheet. 


Large systems like options 71 and 81, may require multiple MSDL cards; 
however, since there is no practical limitation to the number of network slots, 
only loop limitations are considered in these cases. 
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The physical relations of cards discussed above are summarized in Table 4. 


Table 4 


Physical characteristics of cards and modules in Meridian 1 


No. of 
ports/ 
cards 


Card 
slots 


No. of 
loops 


Name of 
card/module 
QPC414 ENET 
NT8D04 XNET 
NT8D17 TDS/CON 


NT8D18 
Network/DTR 


Comments 


Required for MM ports, DTI, PRI loops 
Adjacent slot must be an I/O card 
1 network module, not separable 


Fixed #10 slot in option 21 NT8D11 
network module 


QPC720 PRI/DTI 2 Required for PRI/DTI T1s 
ESDI 1 2 For Mail (CSL), AML, CCR, HER 


DCHI 1 1&1 


SDI 


NT8D11 CE/PE 
module 


NT6D39 
CPU/Network 
module 


NT5D21 
Core/Network 
module 


NT8D35 Network 
module 
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1 DCHI port, 1 SDI port; for PRI & NACD 
For MMax (HSL), CDR 


1 2 
MSDL/MISP 1 4 provides SDI, ESDI and DCHI functions 
7 


Option 21; 
NT8D18 card slot included 


Option 61; CC & extra SDI slot in CE 


Option 61C; CC & extra SDI slot in CE 


Option 71, 81, 81C; extra space for 
options 21/61/61C 
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Note that MSDL cards are available only with X11 release 18 or later. In 
X11 release 18, MSDL supports ESDI and DCHI. With X11 release 19 and 
later, SDI functionality is added to the card’s function. 


1 


General description of card slot requirements 


The option 21 is a single group, single CPU system with limited card 
slots for common equipment. In the NT8D11 CE/PE module, there are 
seven network card slots (slots 4 to 10). The number 10 slot is always 
equipped with the NT8D18 Network/DTR card, which provides DTR 
function and one superloop (four loops) to the IPE cards in the same 
module. Note that there is no address constraint for two adjacent slots for 
option 21. 


For practical applications, one card slot is always equipped with a 
TDS/CON card. The remaining 5 slots can equip 5 XNET cards or 

5 ENET cards. With 6 XNET cards (including the Network/DTR card), 
and one TDS/CON card, the system can have a maximum of 26 loops. 


Alternatively, when all 5 card slots are equipped with ENET cards plus 
the TDS/CON card, the system supports 12 loops. Adding 4 IPE loops 
associated with the NT8D18 Network DTR card, the system can equip a 
maximum of 16 loops (but with no slots for ESDI, DCHI, and so on). 


It is not practical for an option 21/21E to provide PRI without a network 
module for QPC720, since the network shelf allows one loop to interface 
PRI trunks and one loop to connect to the PE module for agent sets, and 
the rest of the slots are used for QPC720, DCHI and Clock Controller 
cards. This leaves very few card slots in the network shelf for other 
applications. With DTI, there is one more slot available (no DCHI) 
which can provide two more loops (if an ENET card is used) or four more 
loops (if an XNET card is used). 


An option 61 consists of two CPU/Network modules and up to five IPE 
and UEM modules. The NT6D39 CPU/Network module has eight card 
slots for Network and I/O cards. In addition, there is a fixed slot for a 
Clock Controller and an SDI which is not included in the eight slots. It is 
assumed that one TDS/CON card is equipped per CPU/Network module. 
Without considering applications, the 14 card slots can support 28 EPE 
or IPE traffic loops. 
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Note that since there are 8 card slots in an NT8D35 module, a maximum 
of 4 NT8D04 Superloop Network cards, or 16 loops, can be equipped per 
module without being adjacent to each other; the other 4 slots can be used 
for I/O cards. 


The option 61 has a maximum of 32 loops, if TDS/CON loops are also 

counted. Note that when a system requires between 16 and 26 loops, it 

can be served by either an option 21 or 61. The decision can be made by 
card slot and real time requirements of the configuration. 


It appears that as long as some IPEs are used, an option 61 will run out 
of loops before it will run out of card slots. For example, in a system of 
14 slots, 7 NT8D04 XNET cards (slots) will use up all 28 loops while 
there are still 7 slots available for other functions. However, if the 
PRI/DTI feature is deployed, the card slots will run out very quickly. 


From a slot perspective, option 61C with the NT5D21 Core/Network 
Module is comparable to option 61 with the NT6D39 CPU/Network 
Module. 


The option 71/81 comprises a maximum of 10 NT8D35 Network 
Modules when the system is fully equipped with 5 groups. Each network 
module has 8 slots for network cards. Therefore, a maximum of 80 slots 
or 160 loops is allowed in the system. As a general practice, we assign 
2 TDS/CON cards to each group, so the number of loops usable for 
general traffic becomes 28. The system capacity becomes 70 slots or 
140 loops. This should be the upper limit for general applications. 


The reason a 5-group system can interface only 10 NT8D35 Network 
Modules is because each group can accommodate a maximum of 

32 loops by equipping 16 QPC414 ENET cards in 16 card slots of the 
two modules in a group. 


If an NT8D35 module is used mainly for providing power and space for 
QPC720 PRI/DTI cards without loops, it is not counted as one of the 
10 modules. Therefore, each supporting module can accommodate 

6 QPC720 doubled sized cards, which are cabled to an NT8D35 module 
with 3 QPC414 ENET cards to provide 6 loops for T1’s. 


Other than potential space limitations in the switch room, the number of 
NT8D35 modules used for providing power and space is unlimited. 
Therefore, the capacity constraint in an option 71 or 81 is the number of 
loops, not card slots. 
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From a slot perspective, option 81C with the NT5D21 Core/Network 
Module is comparable to option 81 with the NT8D35 Network Module. 


Card slot calculation rules 


From the above considerations, the following general rules are used to 
develop the card slot calculation worksheet: 


e A PRI or DTI card (QPC720) takes up two card slots. On one side, 
it interfaces with a T1 carrier; on the other, it interfaces with one of 
the two loops on a QPC414 network card. 


e A DCHI port is required for PRI. This port can be provided by a 
DCHI card (with one other port for SDI) or MSDL card (with three 
additional ports for other functions). 


e A Clock Controller (CC) card is required for PRI or DTI. It will take 
one of the network slots on an option 21 but not on an option 61 
where the CC can be placed on the CE shelf. 


e An XNET card takes one card slot, but its adjacent slot cannot be 
used by either ENET or TDS/CON cards, due to address limitations. 
The slot next to an XNET card can equip only nonnetwork cards 
(such as ESDI, MSDL). This rule applies only to options 61 and 
71/81. Option 21 does not have this restriction, since it has a newly 
designed backplane with four addresses per slot 


e All ENET loops can be lumped together to avoid the inaccuracy in 
rounding off the number of card slots to the higher integer number. 


As can be observed, a PRI or DTI card is very slot expensive due to its 
double width and supporting circuitry requirements. There is no practical 
application on an option 21 that can be equipped with PRI/DTI trunks 
without using a space saving network module. 


In general, IPE cards and superloops should be used as much as possible 
to maximize the utilization of card slots. 


Capacity engineering 


Page 48 of 294 System capacities 


I/O device requirements Most advanced features on the Meridian 1 are 
controlled by auxiliary processors which communicate with the Meridian 1 
CPU on routing and other instructions. Since I/O cards compete with network 
cards for slot space in a network shelf, they are crucial in deciding whether a 
given small system is able to provide all necessary ports and features. Table 5 
summarizes information required to calculate the number of I/O cards needed 
as an input to the card slot calculation worksheet described in the following 
section. 


Table 5 
I/O interface for applications 


Type of 


link/interface Type of port Sync or async 


Application 


AML (associated set) AML 
CCR AML 
CDR RS232 C 
Host Enhanced Routing AML 


Host Enhanced Voice CSL & AML 
Processing 


ISL Modem 


Interactive Voice CSL 
Response 


Meridian Mail CSL 
Meridian MAX HSL 
Meridian 911 AML 


Property Management PMSI Link 
System Interface (PMSI) 


NACD (PRI) 64 kB D-Channel 


TTY (OA&M) RS232 C 


Note: An ESDI card has two ports; an SDI card has two ports; a DCHI card has one DCHI port and one 
SDI port; an MSDL card has four combination ports 
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Certain other applications such as data may require interface to I/O ports. 
Since they are not addressed in the context of a Call Center, they will not be 
covered here. 


By knowing the applications for a given site, the required number of I/O ports 
can be calculated. Depending on the type of I/O cards provided, the number 
of card slots, which will be used as an input to the following worksheet, can 
be determined. 


The Meridian 1 has a maximum of 16 I/O ports for software X11 release 17 
or earlier and 64 I/O ports for X11 release 18 or later, using MSDL. This 
constraint may need to be considered for large systems with many application 
features. For smaller systems, the card slot constraint is a concern, but not the 
maximum number of I/O addresses. 


Algorithm 


The rules described in this section, which are summaries of earlier sections, will 
be implemented in the card slot worksheet for direct application by the user. 


1 Determine TDS/CON card requirements: one card per Network Module 
or 14 loops. 


2 Determine MUSic loop card: one TDS/CON card per music loop. 
3 Calculate ENET cards: the total ENET loops divided by 2. 


4 Clock Controller slot: needed when digital trunks (DTI/PRI) are used for 
option 21. Otherwise, put in a zero in this space. 


5 Calculate XNET card slots: sum up all XNET loops and divide by 4 to 
get the card slots required. For option 21, subtract 4 from the total, since 
the NT8D18 Network/DTR card is always provided. 


6 J/Ocard slot: the number of slots next to XNET cards that are usable only 
for I/O cards, regardless of whether needed or not. This rule is not 
applicable to option 21 network module. 


7  QPC720 DTI/PRI slots: each card takes 2 slots if they are not provided 
through the expanded NT8D35 network module. 


8 The sum of the total card slots above should not exceed 7 for option 21, 
16 for option 61/61C. Under normal applications with expansion 
network modules, the option 71/81/81C should have no physical 
constraints. 
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The algorithm described in this section will be implemented in the card slot 
calculation worksheet. 
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Power consumption 


The power consumption of intelligent peripheral equipment (IPE) and 
peripheral equipment (PE) circuit cards is given in Tables 6 and 7. 


The traffic assumptions used are 25 percent active (9 CCS) for digital and 
analog lines, and 75 percent active (30 CCS) for trunks. These values take the 
average efficiency of the module power supplies into account. 


The power consumption of digital line cards does not vary greatly with traffic, 
as it may with analog line cards. 


Table 6 
Power consumption—IPE cards 


Circuit card Typical power (waits) 


NT8D01AC Controller card-4 

NT8D01AD Controller card-2 

NT8D02 Digital Line card 

NT8D03 Analog Line card 

NT8D09 Analog Message Waiting Line card 
NT8D14 Universal Trunk card 

NT8D15 E&M Trunk card 





NT8D16 Digitone Receiver card 
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Table 7 
Power consumption—PE cards 


Typical power 
(watts) 


Circuit card 

QPC71 E&M/DX Signaling and Paging Trunk card 
QPC192 Off-Premises Extension Line card 
QPC250 Release Line Trunk card 

QPC297 Attendant Console Monitor card 
QPC422 Tone Detector card 

QPC430 Asynchronous Interface Line card 


QPC432 4-Port Data Line card 


QPC449 Loop Signaling Trunk card 


QPC450 CO/FX/WATS Trunk card 

QPC578 Integrated Services Digital Line card 
QPC594 16-Port 500/2500 Line card 
QPC659 Dual Loop Peripheral Buffer card 
QPC723 RS-232 4-Port Interface Line card 


QPC789 16-Port 500/2500 (Message Waiting) Line 
card 
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Table 8 shows power consumption data for each fully configured module. 
This data can be used for rectifier and reserve power (battery) provisioning. 


Table 8 
Meridian 1 module power consumption 


Power consumption 


Module (watts) 


NT6D39 CPU/Network Module 
NT6D44 Meridian Mail Module 
NT8D11 CE/PE Module 
NT8D13 PE Module 

NT8D34 CPU Module 
NT8D35 Network Module 


NT8D36 InterGroup Module 


NT8D37 IPE Module 


NT8D47 RPE Module 
— local site 
— remote site 


Pedestal (with blower unit) 
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Power calculation algorithm The method for calculating Meridian 1 
system power is based on the number of modules and columns in the system, 
regardless of how many cards are initially equipped. This method ensures that 
the external power supply provides adequate capacity, under all conditions 
and all possible growth scenarios, for the modules installed. 


Heat dissipation 


Option 11 does not have a cooling system. Extensive use of circuits on an 
analog card could cause system temperature to rise. Using digital cards for 
agent sets is recommended. 


The other Meridian 1 systems considered here are equipped with cooling 
systems and do not have heat dissipation problems under normal applications. 


Network traffic 


Traffic is a measure of the time a circuit is occupied. On the Meridian 1, the 
circuit normally consists of a path from the set to its line card to a loop 
through the network to another loop, and on to another line or trunk card 
attached to the terminating set or trunk as illustrated in Figure 7. 


Basic traffic terms used in this document are: 


— An ATTEMPT is any effort on the part of a traffic source to seize a 
circuit/channel/time-slot. 


— ACALL is any actual engagement or seizure of a circuit or channel by 
two parties. 


— The CALLING RATE is the number of calls per line per busy hour: 
Calls/Line. 


— The BUSY HOUR is the continuous 60 minute period of day having the 
highest traffic usage; it usually begins on the hour or half-hour. 


— The HOLDING TIME is the length of time during which a call engages 
a traffic path or channel. 


— The TRAFFIC is the total occupied time of circuits or channels, 
generally expressed in CCS or Erlangs: CCS—a circuit occupied 
100 seconds; Erlang—a circuit occupied one hour. 


— BLOCKING—Attempts not accepted by the system due to 
unavailability of the resource. 
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Figure 7 
Network traffic 


Network 
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— OFFERED traffic = CARRIED traffic + BLOCKED traffic. 

— Traffic load in CCS = No. of calls x AHT/100. 

— Network CCS = Total CCS handled by the switching network 
or 


= CCS offered to the network by stations, trunks, attendants, Digitone 
receivers, conference circuits, and special features. 
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A loop is the physical channel that connects a network to the Peripheral 
Equipment (PE). Each loop is designed with a fixed number of time slots (30 
for EPE loops, 120 for IPE, or Superloops). A time slot is a logical one-way 
channel over which voice or data information is passed during a conversation. 
Therefore, two timeslots are used for each normal two-way conversation. The 
load of information, both voice and data, which are transmitted over these 
time slots is called “traffic.” Network traffic capacity is determined by the 
total number of time slots available. 


Given the number of lines and trunks required in the configuration and their 
usage levels, the desired system network size (1.e., the number of 
loops/superloops needed by the system) can be determined. 
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The number of loops needed in the system can be calculated from lines, 
trunks and traffic requirements such as average holding time (AHT) and CCS. 
The algorithms for these computations are described in this section, and 
incorporated into the traffic worksheet in “Network loop traffic capacity 
worksheet” on page 232. 








Option 11 has a non-blocking network. Each card slot is interfaced with a 
DS30X loop which provides 30 channels. CCS per line, trunk or agent is to 
be used to balance traffic among applications. There is no need to calculate 
CCS per loop. 


Enhanced peripheral equipment (EPE) 


With EPE, the loop is an Enhanced Network (ENET) loop, which has 30 time 
slots for general traffic. For an EPE loop, the recommended traffic is 660 CCS 
per loop, which meets all grade of service (GOS) requirements for network 
blocking. For a nonblocking application, a loop can be equipped up to 30 lines 
or trunks, and each circuit can carry up to 36 CCS. Two such loops are 
supported by each QPC414 Network card. 


In addition to supporting standard peripherals (lines and trunks), an ENET 
loop may be used for any of the following functions: 


— TI span (DTI or PRI) 

— Tone and Digit Switch (TDS) 
— Conference Circuit 

— Music Circuit 

— Meridian Mail ports 


Except for TDS and Conference, which have a special IPE card, these 
functions are not supported by IPE. 
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Intelligent peripheral equipment (IPE) 


By combining four network loops, the superloop network card (NT8D04) 
makes 120 timeslots available to IPE peripheral cards. Compared to regular 
network loops, the increased bandwidth and larger pool of timeslots increase 
network traffic capacity for each 120-timeslot bundle by 25 percent (at a P.01 
grade of service). The recommended traffic capacity for an IPE superloop is 
3500 CCS, which meets all GOS requirements for network blocking. For 
nonblocking applications, a superloop can be equipped up to 120 lines or 
trunks, and each circuit can carry up to 36 CCS. 


Lines and trunks 


Line and trunk card assignment will not be discussed in this document. 
Detailed information is available in Meridian I system engineering 
(553-3001-151). This document will present the relationship between lines 
and trunks for the purpose of calculating loop requirements. The traffic 
parcels on a loop can be broken up as shown in Figure 8. 
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Traffic parcels on a loop 
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The following variables, equations and notation (in parentheses) are used to 
determine the provisioning requirements of a Meridian | system. 


Intra-office CCS (SS)—CCS generated by station-to-station calls 
Tandem CCS (TT)—CCS generated by trunk-to-trunk calls 


Originating-outgoing CCS (ST)—CCS generated by station to trunk 
calls 


Terminating-incoming CCS (TS)—CCS generated by trunk to station 
calls 


Line CCS (L) = 2 * SS + ST + TS 
Trunk CCS (T) = 2 * TT + ST + TS 
Total CCS (TCCS) =L+T 


Intra-office ratio (R1)—the portion of the total number of calls which are 
station to station calls 


Tandem ratio (Rt)—the portion of the total number of calls which are 
trunk to trunk calls 


Incoming ratio (I)—the portion of the total number of calls which are 
trunk to station calls 


Outgoing ratio (O)—the portion of the total number of calls which are 
station to trunk calls 


Average holding time (AHT xx)—average holding time for different call 
types (AHTss, AHTtt, AHTst, AHTts) 


Weighted average holding time (WAHT) = (R1 * AHTss) + (Rt * AHTtt) 
+ (I * AHTts) + (O * AHtst) 


Total calls (Calls) = TCCS * 100/22 * WAHT) 
Intra-office calls (Css) = R1 * Calls 

Tandem calls (Ctt) = Rt * Calls 
Originating-outgoing calls (Cst) = O * Calls 


Terminating-incoming calls (Cts) = I * Calls 
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Poisson P.01 Table 


To use the loop requirement calculation worksheet, the number of lines and 
trunks are given as inputs. In order to arrive at the number of trunks needed 
to meet the necessary GOS, the Poisson P.01 table is typically used. This table 
can also be used for other circuits requiring P.01 GOS, for example, RAN 
trunks. Refer to Meridian 1 system engineering (553-3001-151) for P.001 
GOS and other tables. 


The Poisson P.01 table is included here for easy reference. 


Table 9 
Trunk traffic—Poisson 1 percent blocking (Part 1 of 2) 


Trunks CCS | Trunks CCS | Trunks CCS | Trunks CCS 





Note: For trunk traffic greater than 4427 CCS, allow 29.5 CCS per trunk. 
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Table 9 
Trunk traffic—Poisson 1 percent blocking (Part 2 of 2) 


Trunks CCS | Trunks CCS | Trunks CCS | Trunks CCS 





Note: For trunk traffic greater than 4427 CCS, allow 29.5 CCS per trunk. 


Groups 


A network group is comprised of two network modules of 16 loops each for 
a total of 32. The maximum size of a Meridian | is five groups implying 
160 loops. There are two types of loops: terminal loops to provide channels 
for general traffic, and service loops to provide tones and service functions. 
The number of groups in a system is determined by the number of terminal 
loops and service loops required, which was discussed under loop and card 
slot calculations. 


To summarize the general rules, a group normally consists of 28 traffic loops 
and 2 TDS/CON dual loops for a total of 32. A multi-group system comprises 
multiple groups up to a maximum of five. 


Once a system is larger than 32 total loops, a second group is required. To 
communicate between the two network groups, intergroup junctors are used. 


Junctors The intergroup junctor is required once the system grows to be 
two groups or more. A junctor serves as a time slot extension from the 
originating loop of the originating group to the terminating group. The time 
slots on the originating loop and originating junctor need to be matched. 
There are eight one-way junctors from one group to every other group. 
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Topologically, there is a potential concentration of 32 loops from a group to 
8 junctors in an intergroup junctor. With 30 traffic time slots on each junctor, 
240 simultaneous two-way communications between any two groups are 
possible. 


The junctor size is fixed and not engineerable. For special applications with 
high intergroup traffic, the above capacity limitation needs to be considered. 
The normal allowed traffic level per junctor is 660 CCS. 


When lines and trunks are installed, the Community Of Interest (COI) among 
them should be considered, if known. Ports that have high COI should be put 
in the same network group to minimize intergroup junctor traffic. 


Service loops and circuits 


Service circuits are required in call processing to provide specific functions 
to satisfy the requirements of a given application. They are system resources. 
Service circuits also consume system resources, such as physical space, real 
time, memory and so on. This section will describe the traffic characteristics 
of service circuits, their calculation algorithms and their impact on other 
system resources. 


TDS 


The Tone and Digit Switch (TDS) loop in Meridian 1 provides dial tone, busy 
tone, overflow tone, ringing tone, audible ringback tone, DP or dual tone 
multifrequency (DTMF) outpulsing and miscellaneous tones. All these tones 
are provided through the maximum 30 time slots in the TDS loop. 


In other words, the maximum number of simultaneous users of tone circuits 
is 30, whether it be 30 of one tone or a combination of many different types 
of tones. One TDS loop is normally recommended for each Network Module 
or half network group of 14 traffic loops. Additional TDS loops may be added 
if needed, but this is rare. 


Conference 

The CONference loop is a part of the dual loop NT8D17 TDS/CON card. It 
provides circuits for 3-way or 6-way conferences. It can also broadcast music 
from a source to a maximum of 30 users simultaneously. In addition, a CON 
loop also provides temporary hold for a variety of features, chief among them, 
the End to End Signaling. One CON loop is normally recommended for each 
half network group or 14 traffic loops. 
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Option 11 TDS and Conference 

Option 11 has two 16-channel conference loops, eight DTR/DTD channels 
and 30 tone generation channels (TDS) in the COMBO pack. In addition, 
when the daughterboard is equipped, another 16-channel conference loop is 
provided. 


553-3001-149 Standard 9.00 October 1997 


System capacities Page 65 of 294 


Music MUSic is provided through conferencing a caller to a MUS source. 
Therefore, a CON loop is required for the Music on Hold feature. Each set of 
30 simultaneous music users will require a CON loop, thus a TDS/CON card, 
since these two service loops are not separable. For a small system, music 
users can share a conference loop with other applications. However, this is 
not a common practice in Call Center applications. 


The MUS traffic can be calculated by the following formula: 
MUS CCS = # of ACD calls using MUS x MUS HT/100 


A segment of music typically runs from 40 seconds to 60 seconds. If the 
average for a specific application is not known, a default of 60 seconds can 
be used. After CCS is obtained, the MUS port requirement can be estimated 
from a Poisson P.01 table or a delay table (such as DTR table) matching the 
holding time of a MUS segment. 


RAN Recorded Announcement (RAN) trunks are located on 8-port trunk 
cards on PE shelves just like regular trunk circuits. They provide voice 
messages to waiting calls. RAN trunks are also needed to provide music to 
conference loops for music on hold. 


Each RAN trunk is connected to one ACD call at a time, for the duration of 
the RAN message. Different RAN sources require different RAN trunk 
routes. If the first RAN is different from the second RAN, they need different 
RAN trunk routes. However, if the same message is to be used, the first RAN 
and second RAN can use the same route. 


RAN traffic can be calculated by the following formula: 
RAN CCS = # of ACD calls using RAN x RAN HT/100 


ARAN message typically runs from 20 seconds to 40 seconds. If the average 
for a specific application is not known, a default of 30 seconds can be used. 

After RAN CCS is obtained, RAN trunk requirements can be estimated from 
a Poisson P.01 table or a delay table (such as DTR table) matching the holding 
time of a RAN message. 


DTR A Digitone receiver (DTR) serves features involving 2500 sets or 
Digitone trunks. DTRs are system wide resources, and should be distributed 
evenly over all network loops. 
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There are a number of features that require DTRs. General assumptions for 
DTR traffic calculations are as follows: 


Digitone receiver traffic is inflated by 30 percent to cover unsuccessful 
dialing attempts. 


Call holding times used in intra-office and outgoing call calculations is 
135 seconds if actual values are unknown. 


Digitone receiver holding times are 6.2 and 14.1 seconds for intra and 
outgoing calls respectively. 


The number of incoming calls and outgoing calls are assumed to be equal 
if actual values are not specified. 


The major DTR traffic sources and their calculation procedures are as 
follows: 


1 


Calculate intra-office Digitone traffic 


Intra-office = 
100 x Digitone station traffic (CCS) + AHT x (R + 2) 


Recall that R is the intra-office ratio. 
Calculate outgoing DTR traffic 


Outgoing = 
100 x Digitone station traffic (CCS) + AHT x (1-R + 2) 


Calculate direct inward dial (DID) DTR traffic 
DID calls = DID Digitone trunk traffic (CCS) x 100 + AHT 
Calculate total DTR traffic 


Total = [(1.3 x 6.2 x intra) + (1.3 x 14.1 x outgoing calls) + 
(2.5 x DID calls)] + 100 
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weighted average for holding times should be used. 


Table 10 
Digitone receiver load capacity—6 to 15 second holding time (Part 1 of 2) 


Average holding 
time in seconds 


Number of DTRs 
1 


2 
3 
4 
5 
6 
7 
8 
9 


=k 
oO 
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Table 10 
Digitone receiver load capacity—6 to 15 second holding time (Part 2 of 2) 


Average holding 
time in seconds 





Note: Load capacity is measured in CCS. 
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Traffic capacity engineering algorithms 


Traffic capacities of subsystems in the Meridian 1 are estimated based on 
statistical models which approximate the way a call is handled in that 
subsystem. The traffic models used in various subsystem engineering 
procedures are described in the following sections. 


When inputs to the algorithm are lines, trunks, average holding time (AHT), 
and traffic load (CCS), these algorithms can be used to determine the number 
of loops and system size. 


Alternatively, when the loop traffic capacity is known for a given 
configuration, the algorithms can be used to determine the traffic level 
allowed at the line and trunk level while meeting GOS requirements. 


Traffic Models 


The basic assumptions, service criteria, and applicability of the following 
common models will be presented. The underlying assumptions of each 
model are listed: 


1 Erlang B Model 
e Infinite sources (traffic sources to circuits ratio > 5:1) 
e Blocked calls cleared (no queueing) 
e Applicability: loop, ringing circuit blocking 
2 Erlang C Model 
e Infinite sources 
e Blocked calls delayed 
e Infinite queue 
e Applicability: Dial tone delay, I/O buffers, DIGITONE, RAN trunks 
3 Engset Model 
e Finite sources (traffic sources to circuits ratio < 5:1) 
e Blocked calls cleared 


e Applicability: loops with high traffic and low number of sources, 
blocking loops for ACD and data applications. 
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4 Poisson Model 
e Infinite sources 
e Blocked calls held for a fixed length 


e Applicability: incoming/outgoing trunks, DIGITONE, Call 
Registers, RAN trunks 


5 Binomial Model 
e Finite sources 
e Blocked calls held 


e Applicability: small circuit groups, intergroup junctor blocking 


Grade of service In abroad sense, the grade of service (GOS) encompasses 
everything a telephone user perceives as the quality of services rendered, 
including (1) frequency of connection on first attempt, (2) speed of 
connection, (3) accuracy of connection, (4) average speed of answer by an 
operator, and (5) quality of transmission. 


In the context of the Meridian 1 capacity engineering, the primary GOS 
measures are blocking probability and average delay. 


Based on the EIA Subcommittee TR-41.1 Traffic Considerations for PBX 
Systems, the following GOS requirements must be met: 


— Dial tone delay is not greater than 3 seconds for more than 1.5 percent of 
call originations. 


— The probability of network blocking is 0.02 or less on line-to-line 
connections, 0.01 or less on line-to-trunk or trunk-to-line connections. 


— Blocking for ringing circuits is 0.001 or less. 


— Post dialing delay is less than 1.5 seconds on all calls. 


Any connection in the Meridian | involves two loops, one originating and one 
terminating. In an intergroup connection of a multi-group system, it also 
involves an intergroup junctor which can also incur blocking. Each stage of 
connection is engineered to meet 0.0033 GOS. Therefore, overall network 
blocking in the Meridian 1 is less than 0.01, regardless of whether the call is 
a line or trunk call, or an intra- or intergroup call. 
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Signaling and data links 


Serial Data Interface (SDI) 


The SDI is an asynchronous port, providing input access to Meridian | from 
an OA&M terminal, and printing out maintenance messages, traffic reports, 
and Call Detail Recording (CDR) records to a TTY or tape module. An SDI 
card has two ports. A DCHI card has one DCHI port and one SDI port. An 
MSDL card has four ports for a combination of interfaces. SDI is available 
only on an MSDL card with X11 release 19. 


Enhanced Serial Data Interface (ESDI) 

ESDI provides the interface for a synchronous link. An ESDI card has two 
ports. The maximum data rate for an ESDI port is 19,200 bps. An ESDI port 
is primarily used for Application Module Link (AML) types of applications. 


D-channel Interface (DCHI) 


The DCHI card is used for ISDN PRI D-channel signaling; it provides the 
interface for a 64,000 bps synchronous link. A DCHI card has one DCHI port 
and one SDI port. Due to memory limitations on the card, both ports cannot 
be used for D-channel connections. 


Multi-purpose Serial Data Link and Multi-purpose ISDN Signaling 
Processor (MSDL/MISP) 

An MSDL card has four ports providing a combination of SDI, ESDI, and 
DCHI functions. Using MSDL cards, the number of I/O ports in the system 
can reach 64. If older I/O cards are used, the maximum number per system is 
16. The data rate of each port of an MSDL card is dependent on the function 
it provides. The maximum rate is 64,000 bps for D-channel applications, but 
lower for other applications. 


MSDL cards can be only used with X11 release 18 or later. SDI on an MSDL 
is supported only on X11 release 19 software. 
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Functional links 


For each of the following functions, the type of link and resulting capacity are 
given. 


High Speed Link (HSL) 

The HSL is a an asynchronous link, used for the Meridian 1 CPU to 
communicate with the MAX module via an SDI port. Prior to MAX 8, the 
HSL bandwidth was 9600. With MAX 8 and later, 19,200 baud is available. 


Application Module Link (AML) 

AML is a synchronous link between the Meridian 1 and an Application 
Module (AM) through the ESDI port. The data rate of the link can be one of 
the following rates: 300, 1.2kB, 2.4kB, 4.8kB, 9.6kB, or 19.2 kbps. The 
standard setup between the Meridian 1 and an AM is the 19.2 kbps link. 


Meridian Link (ML) 

The Meridian Link is the signaling link between the AM and a host where the 
database for an application resides. The AM serves as an intermediary 
between the Meridian 1 and the host which instructs the Meridian 1 to take 
actions for a specific application. 


Other than maintenance messages for the AM itself, there is a one-to-one 
correspondence between the message a host sends to the AM and the message 
the AM interprets and sends to the Meridian 1, and vice versa. 
Communications between the AM and a host is conducted via standard X.25 
protocols. Therefore, the ML interface is not limited to any particular 
computer vendor’s products. 


For practical applications, the same data rate at the AML and ML is 
recommended. 


Command Status Link (CSL) 

The CSL is the version of AML specifically used for the communications 
between the Meridian 1 and the Meridian Mail system (MM). It has some 
MM specific messages. The interface is through an ESDI port. For Meridian 
Mail 1 through Meridian Mail 9, the CSL link rate was 4800 baud. Beginning 
with Meridian Mail 10, the link rate is 9600 baud. 
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ISDN-AP link 


The ISDN-AP link is an early version of the AML which allows direct access 
by DEC™ machines. Since the ML was developed, all host connections have 
to go through an AM. The AP link is no longer offered as an independent 
product, but it can be a feature in the AML called “AP Pass-through.” 


OA&M 


The Meridian 1 uses an SDI port to connect to a teletype (TTY) to receive 
maintenance commands or to print traffic reports, maintenance messages or 
CDR records. CDR records can also be output directly to a magnetic tape 
system. 


ISDN Signaling Link (ISL) 

An ISL provides common channel signaling for an ISDN application without 
PRI trunks. An analog trunk with modems at the originating switch and the 
terminating switch can be used as an ISL to transmit ISDN messages between 
these two remote Meridian 1s. 


The interface for an ISL is an ESDI port. The maximum data rate for the link 
is 19.2 kbps. 


D-channel 
A PRI interface consists of 23 B-channels and one D-channel. The D-channel 


at 64 kbps rate is used for signaling. A D-channel interfaces with the Meridian 
1 through a DCHI card or a DCHI port on an MSDL. 


A D-channel on a BRI set is a 16 kbps link which is multiplexed to make a 
64 kbps channel. 


Property Management System Interface (PMSI) 

The PMSI allows the Meridian | to interface directly to a customer-provided 
PMS through an SDI port. It is primarily used in Hotel/Motel environments 
to allow updates of the room status database either from the check-in counter 
or a guest room. The enhanced PMSI allows re-transmission of output 
messages from the Meridian 1 to a PMS. The maximum baud rate for this 
asynchronous port is 9600. 
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Table 11 summarizes the above functional links and interfaces and provides 
information required to calculate the number of I/O cards needed as an input 
to the card slot calculation worksheet described later. 


Table 11 
I/O interface for applications 


Application Type of link/interface Type of port Sync or async 


AML (associated set) AML 
CCR AML 
CDR RS232 C 
HER AML 
HEVP CSL and AML 
ISL Modem 
MIVR CSL 
Meridian Mail CSL 
Meridian MAX HSL 
Meridian 9-1-1 AML 
PMSI PMSI Link 
NACD (PRI) D-channel 
TTY (OA&M) RS232 C 


Note: An ESDI card has two ports; an SDI card has two ports; a DCHI card has one DCHI port and one 
SDI port; an MSDL card has four combination ports 
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Processor load 


The Meridian 1 system consists of many processors, of which the Meridian 1 
CPU is the primary one. Others exist in auxiliary platforms such as Meridian 
Mail, and the Applications Module. In this section methods are described to 
determine the load on the Meridian 1 CPU. 


Meridian 1 CPU 


If the Meridian 1 is running X11 release 18 or later software, the call capacity 
report in TFS004 can be used to determine Rated Call Capacity and current 
utilization levels. Otherwise, the idle cycle count method can be used to 
calculate processor load. If a new switch is being configured, equivalent basic 
calls must be calculated, to estimate the processor loading of a proposed 
configuration. 


Idle cycle count method 

A procedure called the “idle cycle count method” is used to determine the call 
capacity and average load on an existing Meridian 1 CPU. Two parameters 
are used in this procedure: idle cycle count, and CPU attempts (also called 
“call attempts”). These are the first and second fields, respectively, of the 
TFS004 traffic report (after the header). Refer to Traffic measurement 
formats and output (553-2001-450) for a description of this report. 


Pairs of these fields, taken over a 24-hour period or longer, are plotted on a 
graph with idle cycle counts on the y-axis, and CPU attempts on the x-axis. 
The locus of points should be a well-defined straight line. If a few of the 
points fall below the line, they probably represent hours in which background 
activities, such as midnight routines, or maintenance were being done. These 
points should be ignored. If the remaining points do not define a clear straight 
line, error conditions and extraneous activities on the switch should be 
cleaned up, and a new set of measurements taken before proceeding. 
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Rated Call Capacity determination 


Rated Call Capacity is the number of featured calls which a switch can handle 
without exceeding its advertised grade of service. The Rated Call Capacity of 
each installation is different, depending on software release, configuration, 
feature mix, and usage patterns. Rated Call Capacity can be determined from 
the graph constructed using the idle cycle count method. 


For simplicity, the following description assumes that the graph was 
constructed from data taken from hourly traffic reports. If half-hourly reports 
were used, the procedure is still valid, but “hour” should be replaced by 
“half-hour” wherever it appears. Note that this means the rated capacity will 
be in terms of calls per half-hour. It should then be doubled, to make it 
comparable. Also, the number of milliseconds in a half-hour is 1,800,000 
rather than 3,600,000. 


The x-intercept is the point on the x-axis where it intersects the plotted line. 
The Rated Capacity of the switch is equal to 70 percent of this value. For 
example, if the line crosses the x-axis at 20,000 CPU attempts, then the rated 
capacity of the switch is: 


0.7 x 20, 000 = 14, 000 Calls-per-hour 


Call Service Time is the average number of milliseconds used up by a call. It 
can be computed by dividing the number of milliseconds in an hour 
(3,600,000) by the value at the x-intercept point. In the example above, the 
call service time is 3,600,000/20,000 = 180 milliseconds. In other words, for 
this particular switch, running with a particular release, and using its unique 
set of features and packages, an average call requires 180 milliseconds of 
processor time. 


Average load determination 


The average load on the processor during a given hour is determined by 

dividing CPU Attempts (from the TFS004 report) by the Rated Call Capacity, 
and multiplying by 100 to produce a percentage. If the load during a certain 
hour on the switch in the above example was 10,500 CPU attempts, then the 


switch was (10,500/14,000) x 100= percent loaded during that hour. 
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Real Time Remaining Required for Upgrade to Later Release 
Tables 12 and 13 show how to determine if a machine, in its present feature 
set configuration, has enough real time capacity to upgrade to a later software 
release. The determining quantity is the “percent CPU utilization”, which is 
obtained from the TFS004 traffic report. Use the tables to translate the percent 
CPU utilization on the “from” switch to the percent CPU utilization on the 
“to” switch by multiplying it times 1 + a percent that is within the range 
shown in the table cell that is located at row “from” present release and 
column “to” destination release. For example, a Release 19 system using 50% 
CPU would be using 50% * (1+.54)= 77% on Release 22. The “.54” is in the 
middle of the range from 42-65% shown in the 19 row, 22 column. 


Table 12 
Real Time Remaining Required for Upgrade (North American stream) 


17 4-6% 8-12% 27-39% 37-56% 53-86% 59-103% 


18 4-6% 23-31% 33-47% 49-75% 55-91% 


19 18-24% 27-39% 42-65% 48-80% 


8-12% 21-33% 26-45% 


12-19% 16-30% 


4-9% 
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Table 13 
Real Time Remaining Required for Upgrade (International stream) 


20-23% 26-32% 36-48% 52-76% 


5-7% 13-20% 27-43% 


8-12% 21-33% 


12-19% 
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Equivalent basic calls 

Real time capacity of a switch can also be specified in terms of Equivalent 
Basic Calls (EBC). An EBC is a measure of the real time required to process 
a Basic Call, which is defined as follows: 


Basic Call: A simple, unfeatured call between two 2500 sets on the 
same switch using a 4-digit dialing plan. Both sets are on 
EPE loops. The terminating set is allowed to ring three 
times, then is answered, waits approximately 2 seconds, 
and hangs up. The originating set then hangs up as well. 
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When the capacity of a switch is stated in EBC, it is independent of such 
variables as configuration, feature mix, and usage patterns. It still varies from 
release to release, and between processors. However, since it is independent 
of other factors, it is a good way to compare the relative call processing 
capability of different machines running the same software release. Table 14 
gives the real time capacity of the various system options for all releases since 
release 17. 


Table 14 
Real time capacity (EBC) by release and system option (EPE equipment) 


X11 release 
System option 
20 


Option 11E N/A 5,800* 5,800 N/A 
ST, option 21 N/A N/A N/A N/A 
STE, option 21E 31,100 24,700 22,450 N/A 


RT, NT, XT, option 51, 38,775 29,650 26,950 N/A 
61, 71 


Option 11C N/A N/A N/A 50,275 


Option 51C/61C/81/81C 81,300 63,000 49,400 43,200 
w/NT6D66 CP card 


Option 51C/61C/81/81C N/A N/A 81,500 67,150 
w/NT9D19 CP card 


Option 51C/61C/81/81C N/A N/A N/A N/A 
w/NT5D10 CP card 


*Options 11E and 11C do not support EPE. The rated capacity in terms of 2500-2500- set IPE 
calls is 6720 calls per hour. However, to use the real-time algorithm, use the adjusted value of 
5,800 calls/hour to be consistent with EPE values used for other options. For option 11C use 
50,275 and 48,350 (adusted from the true IPE values of 58,000 and 55,775) 
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Feature impact 

Every feature which is applied to a call increases the CPU real time consumed 
by that call. These impacts can be measured and added incrementally to the 
cost of a basic call to determine the cost of a featured call. This is the basis of 
the algorithm used by Meridian Configurator to determine the Rated Capacity 
of a proposed switch configuration. Meridian Configurator is supported in 
US, UK, Canada and CALA only. 


The incremental impact of a feature, expressed in EBC, is called the real time 
factor for that feature. Real time factors are computed by measuring the 
incremental real time for the feature in milliseconds, and dividing by the call 
service time of a basic call. 


Each call is modeled as a basic call plus feature increments. For example, an 
incoming call from a DID trunk terminating on a digital set with incoming 
CDR is modeled as a basic call plus a real time increment for incoming DID 
plus an increment for digital sets plus an increment for incoming CDR. 


A second factor is required to determine the overall impact of a feature on a 
switch. This is the “penetration factor.” The penetration factor is simply the 
proportion of calls in the system which invoke the feature. 


The real time impact, in EBC, of a feature on the system can now be 
computed as follows 


(call attempts) x (penetration factor) x (real time factor) 


The sum of the impacts of all features, plus the number of Call Attempts is 
the Real Time Load on the system, in EBC. This number can be compared 
with the real time capacity in Table 14 to determine whether the proposed 
system will handle the load. If the projected real time load is larger than the 
system capacity, a processor upgrade is needed. 
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I/O impact 

There are two types of I/O interface allowed at the Meridian 1: the 
synchronous data link and asynchronous data link. ESDI and DCHI cards 
provide interface to synchronous links, and an SDI card provides interface to 
asynchronous links. The MISP/MSDL card can provide both. 


At the I/O interface, the Meridian 1 CPU processes an interrupt from SDI port 
on a per character basis while processing an ESDI/DCHI interrupt on a per 
message (multiple characters) basis. As a result, the average real time 
overhead is significantly higher in processing messages from a SDI port than 
from an ESDI port. MSDL, however, provides a ring buffer. 


Auxiliary processors 


Interactions with auxiliary processors also have real time impacts on the 
Meridian 1 CPU depending on the number and length of messages 
exchanged. Several applications are described in “Application engineering” 


on page 135. 


Real time algorithm 


As described above, calculating the real time usage of a configuration 
requires information on the number of busy hour call attempts and the 
penetration factors of each feature. 


Busy hour calls 

If the switch is already running, the number of busy hour calls or call load can 
be determined from the traffic printout TFS004. The second field of this 
report (except for the header) contains a peg count of CPU Attempts. A period 
of several days (a full week, if possible) should be examined to determine the 
maximum number of CPU attempts experienced. This number varies with 
season, as well. The relevant number is the average of the highest 10 values 
from the busiest 4-week period of the year. An estimate will do, based on 
current observations, if this data is not available. 
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If the switch is not accessible, and call load is not known or estimated from 
external knowledge, it may be computed. For this purpose, assumptions about 
the usage characteristics of sets and trunks must be made. In particular, the 
average holding time and CCS per hour of each type of line and trunk must 
be estimated. In addition, estimates for the intra-office ratio (RI), the tandem 
ratio (Rt), and the incoming ratio (I) are required. It is also useful to have 
average holding time statistics for intra-office, outgoing/originating, 
incoming/terminating, tandem trunk, and data calls, denoted AHTss, AHTst, 
AHTts, AHTtt, and AHTdata, respectively. Default values are given in 
Table 15. 


Table 15 
Default traffic parameter values 


Parameter Default value 


RI 25 
Rt 05 
AHTss 60 sec 
AHTst 150 sec 
AHTts 180 sec 
ATHit 60 sec 


AHTdata 360 sec 
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Telephones As the primary traffic source to the system, telephones have a 
unique real time impact on the system. For the major types listed below, the 
number of telephones of each type must be given, and the CCS and AHT must 
be estimated. In some cases it may be necessary to separate a single type into 
low usage and high usage categories. For example, a typical office 
environment with analog telephones may have a small call center with agents 
on analog telephones. A typical low usage default value is 6 CCS. A typical 
high usage default value is 28 CCS. 


— Analog: 500, 2500, message waiting 500, message waiting 2500 
telephones, and CLASS sets 


— Electronic: SL-1 telephones 


— Digital: M2000 series Meridian Modular Telephones, voice and/or data 
ports 


— ISDN BRI: voice and data ports 
— Mobility sets 


— Consoles 


Trunks Trunks can be either traffic sources which generate calls to the 
system or a resource which satisfies traffic demands depending on the type of 
trunk and application involved. Default trunk CCS in an office environment 
is 18 CCS. Call center applications may require the default to be as high as 28 
to 33 CCS. 


Voice Analog: 
— CO 

— DID 

— WATS 

— FX 

— CCSA 

— TIEE&M 

— TIE Loop Start 
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Digital: 


— DTI: number given in terms of links, each of which provides 24 trunks 
under the North American standard 


— PRI: number given in terms of links, each of which provides 23B+D 
under the North American standard 


— European varieties of PRI: VNS, DASS, DPNSS, QSIG, ETSI PRI DID 
Data 


— Sync/Async CPU 

— Async Modem Pool 

— Sync/Async Modem Pool 
— Sync/Async Data 


— Async Data Lines 

RAN The default value for AHTran is 30 seconds. 
Music The default value for AHTmusic is 60 seconds. 
Calculations 


— Calculate Total CCS (TCCS) as TCCS=L +T 
— Calculate weighted average holding time (WAHT): 
WAHT = RI x AHTss + Rt x AHTtt + O x AHTst + I x AHTts 
— Calculate total number of calls (Calls): 
Calls = TCCS x 100/ (2 x WAHT) 
— Calculate number of calls for every call type: 
Css = RI x Calls 
Ctt = Rt x Calls 
Cst = O x Calls 
Cts = I x Calls 
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— Calculate CCSs for every type of system traffic: 
SS = 2 x Css x AHTss / 100 
TT = 2 x Ctt x AHTtt/ 100 
ST = Cst x AHTst / 100 
TS = Cts x AHTts / 100 
— Calculate usable line and trunk CCSs: 
Lu = SS + ST + TS 
Tu = TT + ST + TS 
— Calculate line and trunk usage ratios: 
Lr=Lu/L 
Tr = Tu/T 
— Calculate Line and Trunk weighted average holding time: 
WAHTI = (RI x AHTss + I x AHTts + O x AHTst) / (1 - Rt) 
WAHTt = (Rt x AHTtt + I x AHTts + O x AHTst) / (1 - RI) 
— Define SETS to be the total number of sets equipped. 


Features 


Procedures for calculating the penetration factor for various features are 
given below. Since the operation of a telephone switch is extremely complex, 
only features which have high utilization and/or significant real time impact 
are considered. 


In any of the cases, if the feature is not used, the penetration factor is zero. 
500/2500 calls: [Total 500/2500 set CCS x Lr x 100 / WAHTI] / Calls 
SL-1 calls: [Total SL-1 set CCS x Lr x 100 / WAHTI] / Calls 

Digital set calls: [Total digital set CCS x Lr x 100 / WAHTI] / Calls 

BRI voice calls: [Total BRI set CCS x Lr x 100 / WAHT] / Calls 


Data calls: Total data CCS x 100 / AHTdata 
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CLASS calls: [total CLASS set CCS * Lr * 100 / WAHT 1]/Calls 


CPND calls: 
Let CPND set ratio (Rcpnd) = # display sets / # total sets. 
Denote the average CPND name length CPNDI 


The penetration factor is given by 
(Cst + Cts + 2 x Css) x Lr x Repnd x CPNDI / Calls 


CDP calls: O x tie trunk CCS x Tu / (Tu+Tq) x Tr x 100 / WAHTt 


MM (CSL) calls: 

[(Lr x MM CCS x 100 / AHTmm) x (2 x SS + TS) / (SS + TS) / 2] / Calls 
where AHTmm is the average holding time of Meridian Mail calls and 
MM CCS is the total Meridian Mail CCS 


MM (EES) calls: 

[(Lr x MM CCS x 100 / AHTmm) x (2 x SS + TS) / (SS + TS) / 2] / Calls 
where AHTmm is the average holding time of Meridian Mail calls and 
MM CCS is the total Meridian Mail CCS 


NMS (Main) calls: (Lr x NMS_Main CCS x 100 / AHTmm) / Calls 
NMS (Remote) calls: (Lr x NMS_Remote CCS x 100 / AHTmm) / Calls 


Auto Attendant calls: (Lr x AA CCS x 100 / AHTaa) / Calls 
where AA CCS is the total Auto Attendant CCS and AHTaa is the average 
holding time for Auto Attendant calls 


ACD (Inbound) calls: see “Application engineering” on page 135. 





ACD-D/MAX calls: see “Application engineering” on page 135. 





NACD overflowed calls: see “Application engineering” on page 135. 





Meridian Link calls: see “Application engineering” on page 135. 








MLink status messages: see “Application engineering” on page 135. 


CCR/HER calls: see “Application engineering” on page 135. 





IVR (no transfer): see “Application engineering” on page 135. 
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IVR (transfer): see “Application engineering” on page 135. 





Predictive dialing calls: see “Application engineering” on page 135. 





Internal CDR calls: RI, if internal CDR is equipped 
Outgoing CDR calls: O, if outgoing CDR is equipped 
Incoming CDR calls: I, if incoming CDR is equipped 
Tandem CDR calls: Rt, if tandem CDR is equipped 


Authorization code calls: 
0.15 x CO trunk CCS x Tu/ (Tu + Tq) x Tr x 100 / WAHTt 


Off-hook queueing calls: 0.05 x (O + Rt) 
Trunk calls, incoming DTN: (I + Rt) x (%DTN) 
Trunk calls, incoming DIP: (1 — %DTN) x (1+ Rt) 


Trunk calls, outgoing CO: 
[O x CO trunk CCS x Tu / (Tu + Tq) x Tr x 100 / WAHTt] / Calls 


RAN messages: see “Application engineering” on page 135. 





MUSic: see “Application engineering” on page 135. 





BARS/NARS calls: O, if BARS or NARS is equipped 

NFCR calls: 0.1 x O 

DTI calls: [DTI CCS x Tu / (Tu + Tq) x Tr x 100 / WAHTt / Calls 
PRI calls: [PRI CCS x Tu / (Tu + Tq) x Tr x 100 / WAHTt / Calls 


RVQ calls: see “Application engineering” on page 135. 





Superloop calls: 
[Lr x Total Superloop Line CCS x 100 / WAHTI + Tu / (Tu + Tq) x Tr x Total 
Superloop Trunk CCS x 100 / WAHTTt] / Calls 
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Real Time usage For each feature, Real Time Term = Penetration Factor x 
Real Time Factor 


The Real Time Multiplier (RTM) is calculated by 


RTM = 1 + Error_term + > Real_time_term, 


features 


The Error_term accounts for features such as call forward or transfer, 
conference, multiple appearance, and so on, which are not included in the list 
above, and is assigned the value 0.2. In some environments such as Call 
Center, such features are not used, so the Error_term should be given a value 
of 0. 


For each system and software release, there is a measured Basic Call Service 
Time which is the real time required to process a Basic Call. The Rated 
Capacity in Featured Calls is given by 


Rated Call Capacity (FC) = 2520000 / (RTM x Basic Call Service Time). 
Memory size 


In the following discussion, “Gamma” refers to ST and option 21 CPUs. 
Option 21E, STE, option 51, option 61, option 71, NT, and XT contain 
“Omega” CPUs. The option 51C/61C/81/81C w/NT6D66 CP card employs a 
Motorola 68030 CPU, option 51C/61C/81/81C w/NT9D19 CP card employs 
a Motorola 68040 CPU, and option 51C/61C/81/81C w/ NTS5D10 CP card 
employs a Motorola 68060 CPU. Option 11C employs a Motorola 68040 
CPU. 


Memory options 
The following memory cards are available: 
— Option 51C/61C/81/81C w/NT6D66 CP card: 48MB of memory to store 
SL-1 code, SL-1 UDS and PDS plus option 81/61C/51C specific code 
and data. The storage media are 4 MB or 16 MB Single In-line Memory 


Modules (SIMMs) on the CPU board which contains slots for six of 
these. 


— Options 71/61/21: 6 MB boards (2 Mega Word) replace old 2304kB 
boards. 
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— Option 51C/61C/81/81C w/NT9D19 CP card or NT5D10 CP card: Four 
SIMMs of EPROM for storing code. These SIMMs must all be the same 
size — either 8 MB or 16 MB. Currently 8 MB SIMMs are being used. 
Four SIMMs of DRAM for storing data. Each of these SIMMs can be in 
any of the following sizes: 2 MB, 4 MB, 8 MB, 16 MB, or 32 MB. 


Table 16 
Memory sizes (MB) 


Machine Typical Maximum 


Option 11C EPROM 
DRAM 


Option 51C/61C/81/81C EPROM 
w/NT9D19 or NT5D10 CP card DRAM 


Option51C/61C/81/81C w/NT6D66 CP card 


Option 21E/51/61/71 


*96 MB using 16 MB SIMMs 
+12 MB is available only on option 51 and 61 with X11 release 18 or X11 release 19 software 
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Memory for NT and XT machines is supplied on one 6 MB card. Older 
installations may still use one or more 1536 kB memory cards. The number 
of cards used is machine-dependant. Table 17 and Table 18 outline allowable 
combinations of memory by machine type. 





Table 17 
Memory card configurations (ST, STE, NT, XT, option 21, option 51, option 71) 


Board type name “64K” “768K” “OM” “gM” “4M” 


128 2304 


kB kB 6 MB 6 MB 12 MB 


Actual byte size 


Machine Maximum number of boards possible 
ST, STE, option 21 
NT, option 61 
XT, option 71 





Table 18 
Memory configuration by X11 release (ST, STE, NT, XT, option 21, option 51, option 71) 


X11 


R22/R23 
release 


Machine . . . . . i . . Typ. Max. 


ST, STE, 


option 21 


NT, 
option 61 


XT, option 
71 
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Table 19 
Memory card configurations (option 11C/51C/61C/81/81C) 


Board type name “2M “4M “8M “16M “32M 
me SIMM” SIMM” SIMM” SIMM” SIMM” 


Actual byte size 2 MB 4 MB 8MB 16MB 32MB 
Machine Maximum number of SIMMs possible 


Option 51C/61C/81/81C 
w/NT6D66 CP card 


Option 51C/61C/81/81C 
w/NT9D19 or NT5D10 CP card 


Option 11C 


Option 11C EPROM EPROM and disk emulator ROM reside on the 
daughter same daughter board. Presently EPROM has 
board 24Mb and ROM has 8Mb. More capacity can be 
added in 8Mb increments in the form of “baby- 
boards” attached to the daughterboard. 





553-3001-149 Standard 9.00 October 1997 


System capacities Page 93 of 294 


Table 20 
DRAM size as a function of a supported in Release 22 and 23 


Release 22 NT9D19 | NT9D19 CP card | card 


DRAM size a {| 7 
mobility users fone 1500 
supported 
OS heap 3.0000 | 6.0000 | 8.2500 | 12.2500 
allowance (MB) 
Systems with al 
NT9D19 CP ere 
cards that 
support this OS 
heap allowance 


| Release 23 | 23 NT9D19 & NT5D10 | NTODIQANTSDIOCP cards | cards 


DRAM size ee ve 
mobility users hone none none none 5000 
supported 
oe heap 3.0625 | 7.1875 | 6.1875 | 7.7500 8.3750 | 17.5000 
allowance (MB) 
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Table 20 
DRAM size as a function of a supported in Release 22 and 23 


Release 22 NT9D19 | NT9D19 CP card | card 


DRAM size i 
mobility users hofie 1500 
supported 
OS heap 3.0000 | 6.0000 | 8.2500 | 12.2500 
allowance (MB) 





Systems with 51C 51C 
NT9D19 CP 61C 61C 
cards that 81C 

support this OS 
heap allowance 
Systems 51C 

equipped with 
NT5D10 CP 
cards that 

support this OS 
heap allowance 


Table 17 shows how many SIMMs and of what size it is physically possible 
to configure. As of Release 23, SIMMs are configured on the machines in the 
table as follows : 


° 11C DRAM: either 1 x 8MB or 2 x 8MB 


e NT6D66 CP card machines (51C/61C/81/81C) : 4 x 4MB plus 2 x 
16MB 


e NT9D19 and NTSD10 CP card machines (51C/61C/81C) flash 
EPROM : 4 x 8MB 


e NT9D19 and NTS5D10 CP card machines (51C/61C/81C) DRAM : 
see Table 20 
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As shown in Table 20, since the introduction of the mobility feature in 
Release 22, different DRAM sizes are supported according to the number of 
mobility users the site wants to configure. The additional OS heap required to 
support mobility’s dynamic memory use is then allocated during sysload 
according to the amount of DRAM in the system. CP machines are all 
configured with 48MB of memory and they all support 1500 mobility users. 


Memory Upgrade Guidelines 

Upgrades to Option 11C : A customer upgrading to Release 23 on an 11C 
(from 11E) may do so without considering the memory requirements for his 
particular configuration. That is, if it fits on 11E, then it fits on 11C. 


A customer upgrading from Release 22 to Release 23 on an 11C, must 
continue reading. 


Upgrades to option 51C/61C/81/81C machines (Options 
51C/61C/81/81C with NT6D66, NT9D19 and NT5D10 CP cards) and 
from Release 22 to 23 on an 11C: 

A customer upgrading from option 21E/51/61/71 or option 51C/61C/81/81C 
system to Release 23 on an option 51C/61C/81/81C system (with NT6D66 or 
NT9D19 CP card) must consider the size of his SL-1 database, in terms of 
Release 23. With this knowledge he can then determine if the 48 MB on the 
NT6D66 CP card is adequate for his needs, or, if he is upgrading to an option 
11C or an option 51C/61C/81/81C system equipped with an NT9D19 or 
NTSD10 CP card, which size system and how much DRAM he will need. 


To make this determination, take the following steps : 


- Use MEMAVAIL display in SL-1 database user interface to determine 
the size of the SL-1 customer database on the system being upgraded from. 
The “USED” field in the MEMAVAIL display, returned by the SL-1 user 
interface after loading any service change overlay that can add or delete data 
(eg., overlay 11), gives the present size (in memory) of the SL-1 customer 
data base in SL-1 words. (This quantity, will be referred to as 
“SL1IDB-words’’.) 


- Compare your SLIDB-words with the limits shown in Table 21 below 
to see if your memory requirement is small enough to be able to upgrade to 
Release 23 on the desired machine type. 


- If your customer database size is too large to upgrade to the desired 
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machine type and/or DRAM size, it may be possible to make it fit by 
configuring fewer call registers. (This is done in Overlay 17 - the 
configuration record user interface - with the NCR prompt after you have 
answered “Yes” to the PARM (change system parameters) prompt. Note that 
a system INIT is then required to make this change become effective.) In 
Table 21 below are shown the recommended call register counts for each 
machine type, and their corresponding claims on SL-1 customer database 
memory. Use this as a guide to try for an optimal call register count. (As 
shown in the table call registers use memory at a rate of 197 words per call 
register.) 


Table 21 
MEMAVAIL USED upper bounds for UPGRADE (units = SL-1 words) 


Machine being | Systems Systems Systems Systems Systems Systems 
upgraded TO : with with with with with with 
(columns) NT6D66 NT9D19 NT9D19 NT9D19 NT5D10 NT5D10 
CP card, and and and CP cards, | CP cards, 
48MB NT5D10 NT5D10 NT5D10 48MB 48MB 
Release being | total CP cards, | CP cards, | CP cards, | DRAM DRAM 
upgraded memory 16MB 32MB 32MB and no and 5000 
FROM : and 1500 DRAM DRAM DRAM mobility mobility 
mobility. and no and no and 1500 
sicieicy | Mobility | mobility | mobility | 81° 81C 


81/81C 51C 51C/ 51C/61C 


61C L 81C 
(NT9D19 (NT9D19 
CP card (NT9D19 CP card 


P 
only) a only) 


(rows) 


upgrading from options 21E/51/61/71 


Release 19 1,290,991 
903,173 3,368,028 | 2,418,005 | 6,132,206 | 4,232,159 
Release 20 
1,565,453 | 1,095,186 | 4,084,066 | 2,932,069 | 7,435,903 | 5,131,910 
Release 21 
1,807,387 | 1,264,442 | 4,715,240 | 3,385,207 | 8,585,088 | 5,925,023 


upgrading from options 51C/61C/81/81C systems equipped with NT6D66 
and NT9D19 CP cards 
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Table 21 
MEMAVAIL USED upper bounds for UPGRADE (units = SL-1 words) 


Machine being | Systems Systems Systems Systems Systems Systems 
upgraded TO : with with with with with with 
(columns) NT6D66 NT9D19 NT9D19 NT9D19 NT5D10 NT5D10 
CP card, and and and CP cards, | CP cards, 
48MB NT5D10 NT5D10 NT5D10 48MB 48MB 
Release being total CP cards, | CP cards, | CP cards, | DRAM DRAM 
upgraded memory 16MB 32MB 32MB and no and 5000 
FROM : and 1500 DRAM DRAM DRAM mobility mobility 
mobility. and no and no and 1500 
sicc | Mobility | mobility | mobility | 8! G ete 


81/81C 51C 51C/ 51C/61C 


61C e 81C 
(NT9D19 (NT9D19 


CP card MBb CP card 
only) only) 


only) 


Release 19 

968,243 677,380 2,526,021 | 1,813,504 | 4,599,155 | 3,174,119 
Release 20 

1,174,090 | 821,390 3,063,049 | 2,199,052 | 5,576,928 | 3,848,932 
Release 21 

1,355,540 | 948,332 3,536,430 | 2,538,905 | 6,438,816 | 4,443,767 
Release 22 

1,491,094 | 1,043,165 | 3,890,073 | 2,792,796 | 7,082,698 | 4,888,144 


(rows) 


upgrading from 11C 
to 11C 


8 MB 16 MB 
DRAM DRAM 
Release 22 167,636 1,120,074 


*A 32 MB DRAM is optional with 51C and 61C systems equipped with 
NT9D19 and NT5D10 CP cards. 16 MB DRAM is the default. 48MB DRAM 
is optional on 81/81C machines with NT5D10 CP cards. 32 MB is the default. 
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Table 22 provides the maximum recommended call register count by machine 
type. A particular configuration on a given software release may be able to 
configure a greater number of call registers, but there is no assurance that this 
higher number of call registers will be supported in subsequent releases of 
hardware and/or software. 


Table 22 
Recommended Maximum Call Register Counts and Release 23 Memory Implications 


11C & 81 / 61C 


we 61C 51C ee with 81C with 51C with 61C with 81C with 


5 with with with with 
Machine Type NT6D66 NT6D66 NT6D66 NT9D19 NT9D19 NT9D19C NT5D10C NT5D10C NT5D10C 
CP P card P card P card P card 


CP CP card CP CP card 
card 
card card 


Recommended 
Call Register 1000 2000 5000 1500 3000 7500 2000 4000 10000 


Count 


Memory 197,000 394,000 985,000 295,500 591,000 1,477,500 394,000 788,000 1,970,000 
Required (SL-1 

words) (Release 

23) 


Memory 0.7515 1.5300 3.7575 1.1273 2.2545 5.6363 1.5300 3.0600 7.6500 
Required (MB) 





In Release 23, call registers are 197 SL-1 words long. One SL-1 word is 4 
bytes. 
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Note: Sites experiencing memory shortages during an upgrade should 
check that the call register counts are within the bounds set by this table. 


Many sites with 51C and 61C systems equipped with NT6D66 CP cards had 
been running with 5000 call registers because that was documented as a 
recommended maximum in previous releases when the recommendations 
were less machine specific. (There have also been sites trying to run with a 
great deal more than that.) Since all systems equipped with the NT6D66 CP 
card have the same amount of memory, the count recommended for the larger 
machines (81, 81C) will also fit into memory on the smaller ones. However, 
when these sites then go to upgrade to a NT9D19 or NT5D10 CP card, and 
opt for the smallest DRAM size (16MB) supported on 51C/61C, then there is 
no longer sufficient memory for the 81/81C sized call register count. In order 
for the system to run properly or even complete sysload it is imperative that 
the call register counts be reduced to the recommended maximums. 


Memory partitioning 


Table 23 
Memory partitioning for NT, XT, 61,71 systems 


Memory allocation Function 


0 to 6kB Fast RAM 
6kB to (12kB to 180kB) Unprotected global variables 


(12kB to 180kB) to 192kB Protected Global Variables and data store 


192kB to 204kB ROM 


204kB to (204kB to Program store 
12 MB) 


(204kB to 12M) to 36 MB Protected and unprotected data 
36 MB to 48 MB Input/output 
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Table 24 


Release 23 memory map for systems equipped with NT6D66 CP cards w/ 48 MB DRAM 


Memory bucket description 


top of memory 
OS upper address miscellany 


space for patches 


space for SL-1 customer data (udata is at the top and grows 


down, pdata is at the bottom and grows up) 
sli resident code’s fixed data 

overlay code 

sli resident code 

OS dynamic heap 

OS code’s fixed data 

OS code 


OS lower address miscellany 
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HEX address 
of lower 
boundary 


7000000 
6fd0000 

6e30000 
63e0000 


6290000 
5db0000 
4d50000 
41a0000 
4170000 
4040000 
4000000 


# 64KB 
pages 
occupied / 
#MB 
occupied 


0/0 
3/0.1875 
26 / 1.6250 
158 / 9.8750 


20 / 1.2500 
78 / 4.8750 
262 / 16.3750 
187 / 11.6875 
3/0.1875 
19 / 1.1875 

4 / 0.2500 
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Release 23 DRAM map for systems equipped with NT9D19 and NT5D10 CP cards (32MB 


1500 mobility users example) 


DRAM bucket description 


top of DRAM 


OS upper address miscellany (includes 1MB for CPU 
switchover operations) 


space for patches 


OS reserved for the remainder of OS dynamic heap 
requirement 


space for SL-1 customer data (udata is at the top and grows 
down, pdata is at the bottom and grows up) 


sl1 resident code’s fixed data 
OS dynamic heap base portion 
OS code’s fixed data 


OS lower address miscellany 


HEX address 
of lower 
boundary 


a000000 
9ed0000 


9d30000 
9700000 


8800000 


86b0000 
8080000 
8040000 
8000000 


# 64KB 
pages 
occupied / 
#MB 
occupied 


0/0 
19/ 1.1875 


26 / 1.6250 
99 / 6.1875 


240 / 15.0000 


20 / 1.2500 
99 / 6.1875 
4/0.2500 
4/0.2500 
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Table 26 
Release 23 Flash EPROM map for systems with NT9D19 and NT5D10 CP cards 


# 64KB 
HEX address pages 
of lower occupied / 
boundary #MB 
occupied 


pages 


Flash EPROM bucket description 
actually used 


top of flash EPROM 6000000 0/0 
flash file system 5c00000 64 / 4.0000 


overlay code (this is also resident, but is 5400000 128 / 8.0000 
built as a separate unit) 


sl1 resident code 4300000 272 / 17.0000 


OS code 4100000 32 / 2.0000 
boot rom 4000000 16 / 1.0000 





In Table 24 and Table 25, addresses and pages occupied apply to the Gate IT 
issue of Release 23. They are highly subject to change and are only included 
as a means of illustration. In the flash EPROM map (Table 26) note that code 
buckets begin at integral MB boundaries, and not all pages in the bucket are 
necessarily used. 
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Memory engineering 


Program store 

Option 51/61/71 The size of program store is dependent upon the release 
and the number of packages included. The number and size of the packages 
included can vary in any given installation. Packages 0, 1, and 2 are 
considered non-optional. In practice, at most 94 percent of available packages 
are used in any given installation. In Table 27, resident SL-1 program store 
figures include resident code size + resident code overhead + ROM + overlay 
area + all optional packages. 


Option 110/51C/61C/81/81C The number of packages included is fixed; 
that is, all packages are included. Therefore, the program store requirement is 
fixed, see Table 29. 


Table 27 
Program store size (kB) for NT, XT, 61, 71 assuming all packages loaded 


X11 release 


15 16 17 18 19 20 


Resident SL-1 912 1116 1200 1347 1680 2113 3686 4004 
program store 


Overlay SL-1 N/A 1131 1173 1185 1404 1428 1792 1872 
code 





Table 28 
Program store size (MB) for option 11C/51C/61C/81/81C 


Category X11r18 X11r19 X11r20 X11r21 X11r22 X11 r23 


Code: 
Resident SL-1 code 4.5625 5.5625 9.4375 10.6875 15.8750 16.3750 


Overlay SL-1 code 3.3750 3.5000 4.5000 4.5000 4.7500 4.8125 
Option 81/61C/51C OS 0.6250 0.6250 0.6875 0.8125 1.0000 1.0625 


Code size total 8.5625 9.6875 14.6250 16.0000 21.6250 | 22.2500 
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Option 11C0/51C/61C/81/81C OS Dynamic Memory 

and Patching Area 

The Motorola processor (with VxWorks OS) based machines require special 
memory allocations in addition to that for code and customer data. These 
allocations are : an area for patching, various fixed memory allocations for 
OS (not all contiguous - this includes fixed variables for SL-1 and OS code, 
reserved areas at the very top and bottom of memory (see “Memory 
partitioning” on page 99.)), and a special area reserved for dynamic OS heap 
allocations. Since Release 22 the OS heap includes memory allocated by 
SL-1 features via the VxWorks OS. In previous releases, the OS heap was 
used exclusively by the OS. 


Table 29 
Patching, Overhead and OS Heap (MB) for option 51C/61C/81/81C w/ NT6D66 CP card 


X11 X11 X11 x11 


Category release 20 release21 release 22 release 23 


Patching Area 1.5000 1.5000 2.1250 2.1250 


Miscellaneous Fixed Overhead i 4 1.6875 1.7500 
OS Dynamic Heap 1.8125 2.0625 10.7500 11.6875 


3.3125 3.5625 14.5625 15.5625 


*Previous to Release 22, the fixed overhead and OS dynamic heap were 
lumped together in a single memory use partition. 





Table 30 Patching, Overhead and OS Heap (MB) for option 11C 


X11 release X11 release x11 x11 
Category 22 22 release 23 release 23 
(no (500 (no (500 
mobility) mobility) mobility) mobility) 


Patching Area 1.0000 1.0000 1.0000 1.0000 
Miscellaneous Fixed Overhead 1.3103 1.3103 1.2702 1.2702 
OS Dynamic Heap 3.6100 4.9476 4.2328 7.4725 


Total 5.9203 7.2579 15.5625 9.7427 
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Table 31 
Patching and OS Heap (MB) for option 51C/61C/81/81C w/ 
NT9D19 card and NT5D10 card 


X11 X11 X11 X11 X11 
release 22 release22 release23 release23 release23 
16MB 32MB 16MB 32MB 48MB 
DRAM DRAM DRAM DRAM DRAM 


Category 


Patching Area 2.1250 1.1250 2.1250 2.6250 
Miscellaneous Overhead 2.6875 2.7500 2.7500 2.7500 


OS Dynamic Heap 


8.2500 


12.2500 12.3125 


not 17.5000 
5000 mobility users not not 


supported 
supported | Supported pp supported 





On the NT9D19 and NT5D10 processors, the size of the patching area is a 
function of DRAM size. OS dynamic heap size is a function of DRAM size 
and mobility option. (See also Table 20 “DRAM size as a function of 
Mobility supported in Release 22 and 23” on page 93). 


Data store 

The data store consists of both protected and unprotected database 
information. This section describes the information stored in each area and 
how to determine the values for input to the memory size worksheet (see 
“Memory size worksheet” on page 248). 
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Protected data store 


— Telephones: 
Assumptions: 
e average number of features defined per 500/2500 telephone is 8 


e average number of 500/2500 telephones sharing the same template 
is 10 


e average number of key lamp strips per SL-1 telephone is 1 


e average number of SL-1/Digital telephones sharing the same 
template is 2 


e average number of non-key features per digital set is 4. 


Calculations: 


e For every type of set the protected data store size is calculated using 
basic formula: Number of items x MS per item. 


The following items are included here: 
e 500/2500 telephones 

e SL-1 telephones 

e ACD telephones 

e M2006/2008/2009 telephones 
e  M2016/2216/2616 telephones 
e M2112 telephones 

e M2018 telephones 

e M2317 telephones 

e M3000 telephones 

e Consoles 

e Add-on Modules 

e Templates 


e Attendants 
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DS/VMS access TNs: 

(Number of Meridian Mail ports + Number of data ports only) x 
MS per DS/VMS access TN 

Office Data Administration (ODAS): 

(Number of Meridian Mail ports + Number of data ports only + 
Total number of sets + Number of analog trunks) x MS for ODAS 
Customers: 

Constant term + Number of customers x MS per customer 
Directory Number (DN) translator: 

Assumptions: 

e the two lowest levels in the DN tree have average rate of 8 digits 


e the rest of the DN tree has a structure which provides the lowest 
possible digit rate for upper levels 


Calculations: 
¢ 5.8 x Number of DNs + 2 x (2 x Number of ACD DNs + 


e Number of ACD positions + Number of DISA DNs) + MS per 
console x Number of consoles + Number of dial intercom groups 


Dial Intercom Group (DIG) translator: 


Maximum number of DIGs + 2 x (number of DIGs + Total number of the 
sets within DIGs) 


Direct Inward System Access (DISA): 
Number of DISA DNs x MS per DISA DN 
Authorization Code: 

Assumption: 


e the length of the authorization code is in the range of 4 through 7 


Calculations: 


e Number of customers x MS per customer + 1.47 x Number of 
authorization codes 
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— Speed Call: 
Maximum number of Speed Call lists + Number of Speed Call lists x 
(3 + 0.26 x Average number of entries per list x DN size) 
— Analog trunks: 
Number of analog trunks x MS per analog trunk 
— Trunk Route: 
Constant term + Number of trunk routes x MS per trunk route 
— Network: 
Number of groups x MS per group + Number of local loops x 
MS per local loop + Number of remote loops x MS per remote loop 
— TDS, MF sender, Conference, DTR, Tone Detector: 
Number of DTRs x MS per DTR + Number of TDSs x MS per TDS 
Number of MF senders x MS per MF sender + 
Number of conference cards x Ms per conference card + 
Number of TDETs x MS per TDET 
— ISDN PRI/PRI2: 
Number of D-channels x MS per D-channel + Number of PRI trunks 
+ Number of ISL trunks 
— ISDN DTI/DTI2Z/JDMI: 
Number of DTI loops x MS per DTI loop + Number of DTI2 loops x 
MS per DTI2 loop 
— History file: 


Size for history file buffer 
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— Basic Alternate Route Selection/Network Alternate Route Selection 
(BARS/NARS): 
Assumptions: 
e the length of any code = 3 


e the typical structure of the tree for every code (in term of digit rate) 
is the following: 


10-10-10.... - for SPN code 

8 -10-10.... - for NX X/LOC code 

6-2-10-8-10... - for NPA code 
Calculations: 


5684 + 31.21 x number of NPA Codes + 1.06 x Number of NXX 
Codes 


+ 1.06 x (Number of LOC Codes + Number of SPN Codes) + 
2 x Number of FCAS Tables 
— ISDN Basic Rate Interface (BRI): 
Number of MISP boards x MS per MISP board + 
Number of DSLs x MS per DSL + Number of TSPs x MS per TSP 
+ Number of BRI DNs x MS per BRI DN 
— Coordinated Dialing Plan (CDP): 


Constant term + 3 x Number of steering codes + 8 x Number of route lists 
+ 3 x Total number of entries in route lists 


— Call Party Name Display (CPND): 


Number of trunk routes + Number of consoles + Number of ACD DNs 
+ Number of SL-1 DNs + Number of digital set DNs 


+ Number of Names x (5 + Average length of name) 
+ Number of 1-digit DIG groups x 11 
+ Number of 2-digit DIG groups x101 
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— Feature Group D (FGD) Automatic Number Identification (ANI) 
Database: 
Assumptions: 


e all Numbering Plan Area (NPA) codes designated for BARS/NARS 
are assumed to be used for ANI also 


e one NPA block is assumed for every fifty NPA codes 
e five NXX blocks are assumed for each NPA block 
e twenty SUB blocks are assumed for each NXX block 
Calculations: 
e 3x Number of NPA Codes + 658 x Number of NPA codes 
— Automatic Call Distribution (ACD)/Network ACD (NACD): 
Number of ACD DNs x MS per ACD DN + 
Number of NACD DNs x MS per NACD DN + 
Number of ACD positions x MS per ACD position + 
Number of ACD agents + 11 x Number of customers 
— Fixed address globals: 
MS for fixed address globals 


Unprotected Data Store 


— Telephone: 


For every telephone type (except BRI telephones) the memory size is 
calculated as 


e Number of telephones x MS per item, where MS per item depends 
on the set type. For example: 


e Number of 2500 telephones x MS per 2500 set, 
e Number of telephones with display x MS per display, and so on 
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— BRI telephones: 
Constant term + MS per MISP x Number of MISPs 
+ MS per DSL x Number of DSLs + MS per BRI line card x Number 
of BRI line cards, 
where 
MISP stands for the Multi-purpose ISDN Signaling Processor 
DSL stands for the Digital Subscriber Loop 
— Analog trunks: 
The following types of the analog trunks are considered: 


Paging trunks, RAN trunks, AUTOVON trunks, Add-on Data 
Module (ADM), RLA trunks, other analog trunks. 


Calculations: 
e Number of paging trunks x MS per paging trunk 


e Number of other analog trunks x MS per other analog trunk, and so 
on 


e (Number of other analog trunks = Total number of analog trunks — 
Number of paging trunks — Number of RAN trunks — Number of 
AUTOVON trunks — Number of ADMs — Number of RLAs) 


— Trunks (Call Detail Recording [CDR]): 
Total number of trunks x MS per trunk 
— BRI trunks: 
Number of BRI trunks x MS per BRI trunk 
— Trunk routes: 


Number of trunk routes x MS per trunk route + Total number 
of trunks / 16. 


Note: The result of division should be rounded up. 
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System capacities 


— DTI/DTI2/JDMI: 


e Number of DTI loops x MS per DTI loop 
e Number of DTI2 loops x MS per DTI2 loop 


— ISDN PRI/PRI2/ISL 


PRI: 


e Number of D-channels x MS per PRI D-channel + Number of 
outputs 


e Request buffers x MS per output request buffer + 
e 2x (Number of PRI trunks + Number of ISL trunks) 


PRI2: 
e Number of D-channels x MS per PRI2 D-channel + Number of 
output 


e Request buffers x MS per output request buffer + 
e 2x (Number of PRI trunks + Number of ISL trunks) 


Teletypes: 

Total number of teletypes x MS per teletype 
Number of CDR links x MS per CDR link 
Number of HS links x MS per HS link 
Number of APL links x MS per APL link 
Number of PMS links x MS per PMS link 
Number of Other links x MS per other link 
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— For the following items (features) memory size is calculated using the 
basic formula 
Number of items x MS per item 
where item is one of the following: 


local loops, remote loops, secondary tapes, customer, Tone and 
Digit Switch, MF sender, Conference card, Digitone receiver, Tone 
Detector, attendant, Peripheral Signaling card, LPIB, HPIB, 
background terminal, MSDL card 


Note: The size of High Priority Input Buffer = Number of Groups x 32. 


— PBXOB and BCSOB: 
Number of Peripheral Signaling Cards x 640 
Number of Peripheral Signaling Cards x 640 
— DS/VMS access TNs: 
MS per DS/VMS TN x (Number of Meridian Mail Ports + 
Number of data only ports) 
— Application Module Link (AML): 
Constant term + Number of AMLs x MS per AML 
— Automatic Call Distribution (ACD): 
If ACD-C package is not equipped, then memory size for ACD feature is 
Number of ACD DNs x 298 + Number of ACD positions x 34. 


If ACD-C package is equipped, then additional memory size for ACD-C 
feature is 


Number of ACD-C routes x 46 + Number of ACD-C positions x 42+ 
Number of ACD-C DN’s + Number of control directory numbers x 
80 + Number of ACD-C trunks + Number of ACD-C CRTs x 30 + 
Number of customers with ACD-C package x 240. 
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— NARS/BARS/Coordinated Dialing Plan (CDP): 


Assumption: 


if NTRF package is equipped, then Off Hook Queuing (OHQ) is also 
equipped 


Calculations: 


MS per customer x Number of customers + 2 x (Number of route 
lists x MS per route list + Number of routes with OHQ x MS per 
route + Number of NCOS defined x MS per NCOS) 


— Call registers: 


Assumptions: 


The Call Register Traffic Factor = 1.865; 


The formula for the calculation of recommended Number of Call 
Registers depends on traffic load for the system; 


28 CCS per ACD trunk. 


Calculations: 


Call Registers Memory Size = Recommended number of call 
registers x MS per call register 


Snacd = Number of Calls Overflowed to all target ACD DNs x 2.25 
— Number of calls overflowed to local target ACD DNs x 1.8 (0, if 
the system is not a source node) 


Tnacd = 0.2 x Number of expected calls overflowed from source (0, 
if the system is not a target node) 


ISDN CCS = PRI CCS + BRI CCS 
ISDN penetration factor: 
p = ISDN CCS / Total Voice Loop Traffic 


553-3001-149 Standard 9.00 October 1997 


System capacities Page 115 of 294 


* ISDN factor = (1 - p)+ 4x (1 -p)x p+3xp? 
e  IfTotal Voice Loop Traffic > 3000 CCS, then 


e Recommended number of call registers = (0.04 x Total Voice Loop 
Traffic + 0.18 x Number of ACD incoming trunks + Snacd + Tnacd 
+25) x ISDN factor 


e If Total Voice Loop Traffic < 3000 CCS, then 


e Recommended number of call registers = (Number of system 
equipped ports — Number of ACD incoming trunks — Number of 
ACD agent sets) x 0.94 + Number of ACD incoming trunks + Snacd 
+ Tnacd x ISDN factor 


— Fixed address globals and OVL data space: 
MS for fixed address globals + MS for OVL data space. 


Overlay Cache (Omega systems only) 

A Release 18 feature, Overlay Cache Memory, provides speedy access to 
overlays, but it also has the potential of significantly impacting memory 
usage. Average cache memory is considered to be five buffers, the maximum 
to be 32 buffers, at 57 Kbytes each. It is the largest impact on data store 
requirements for Release 18 and has the potential of using up to 1.8 Mbytes 
of memory out of a total of 6 Mbytes. However, the typical configuration of 
only five overlay buffers reduces incremental memory usage to 285 Kbytes. 
Systems may be configured with 2 to 32 overlay cache memory blocks of 19 
kB each. Defining overlay cache buffers reduces the amount of memory 
available for data store. 


Mass storage size 


The Meridian 1 processor program and data are loaded from hard disk and/or 
floppies. The auxiliary processor operating system, programs, and data for 
such applications as Meridian MAX, Meridian Mail, Customer Controlled 
Routing, and Meridian 911 are loaded from tape. The capacities of these 
media along with brief descriptions of the layouts used for all processor types 
and applications are discussed in this section. 
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Meridian 1 processors 


Meridian 1 processors include the Omega processors: (ST, STE, NT, XT, and 
options 21, 21E, 51, 61, and 71), and Thor processors: (options 51C, 61C, 81 
and 81C). Thor systems have a very different architecture from the Omega 
systems. Thor and Omega are addressed in separate sections because their use 
of mass storage is fundamentally different. 


Omega processors 


On Omega systems, the hard disk and the floppies are laid out identically and 
perform the same function. The user can choose whether to upload/download 
from/to hard disk or floppy by selecting the appropriate options in the 
database configuration record (LD 17). Table 32 illustrates the possible 
interactions between these two disk types and CPU. 


Since release 20B, all systems have hard drives. Unattended sysload is 
supported only from hard disk, not from floppy, since more floppies are 
required to complete the load than there are floppy drives. 


Table 32 
Hard disk/floppy disk/CPU interactions 


Interaction Function performed 


Floppies —> CPU Sysload program and data (if system has been configured for floppy 
sysload in LD 17) 


CPU — floppies Dump database (LD 43) 
Floppies — hard disk RESTORE database from floppies to hard disk (LD 43) 
Hard disk — floppies | BACKUP database from hard disk to floppies (LD 43) 


CPU —> hard disk Dump database (LD 43) 


Hard disk + CPU Sysload program and data (if system has been configured for hard disk 
sysload in LD 17) 
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Typically, the hard disk total area (up to 300,000 1-kB records) greatly 
exceeds that provided by the set of floppies (up to 4 floppies at up to 2850 
1-kB records each). As a result, the hard disk has not been a constraining 
factor, whereas SL-1 program growth and data base expansion have required 
several upgrades to larger and larger floppies. Table 33 shows the history of 
floppy drive upgrades. 


History of floppy drive upgrades 


Introductory 
X11 release 


X11 release 9 
X11 release 14 


X11 release 18 


# of 1kB Corresponding* 


Disk type records per floppy Floppy (MB) hard disk (MB) 


5 1/4 inch 1140 records 1.1 MB 10 MB 
31/2inch 1425 records 1.4 MB (“2MB”) 20 MB 


31/2inch 2850 records 2.8 MB (“4MB”) 40 MB or higher 


* Hard disk and floppy controls reside on the same card. A floppy upgrade implies a hard drive upgrade as 





well. 


Calculating floppy disk capacity for ST and option 21 

The information in this section will help you decide whether your existing 
floppy disk configuration is satisfactory or a disk upgrade is required. 
Information on memory limitations for ST and option 21 systems is also 
presented. 


Note: ST and option 21 systems cannot run X11 release 18 or later 
software. Therefore, this discussion is only applicable to 2 MB 3.5 inch 
floppy disks. 


To determine if you have adequate disk space, you must determine available 
disk space when upgrading or expanding an existing system (the system 
provides the information during data dumps). The data presented is, at best, a 
rough approximation of the actual data on disk. 


If the space required for data exceeds or approaches the available space, you 
must upgrade to 3.5 inch disks and/or a hard drive. It is wise to allow room 

for growth and uncertainties in the calculation, however it is suggested that 

you upgrade only when necessary. 
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Disk space available for data Use the following equation to determine 
available disk space: 


Space available for data = Space available — Space required for software. 


Space available on floppy disks = Storage space of disk type x Number of 
disks. See Table 18. 


Table 34 
Storage space for floppy disk types 


Disk type 5.25 inch 3.5 inch 


Storage 1140 records 1425 records 





For example, using two 3.5 inch disks, the storage space available is: 


2 x 1425 = 2850 records 


Disk space required for software (S/W) = Basic system + Optional packages 
+ Packing factor. 


Table 35 
Disk space required for software in records 


Software 
Basic system* (no optional packages) 
Optional packages 


kkk 


Packing factor 


*Basic system = Basic software load + Directory + Firmware + Sysload1 + Overlays 
+ Intrinsics + Configuration + End of file 


**You can determine the number of records for options by adding the number of 
records per package for a specific machine type. 


***Packing factor allows for the possibility of unusable space when disks are 
formatted to specific customer requirements. In the worst case, this is up to 80 
records. 
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Disk space required for data = Space currently occupied by data (printed 
during data dump) + Growth of data blocks* + Allowance for future system 
growth (at customer’s discretion). 


*At best, this is only an approximation and is dependent on 
configuration. 


Table 36 
Data block growth by upgrade to X11 R17 


Use this percentage of 
Upgrading to R17 from X11 release: Space currently 
occupied by data 


R9 and R10 
R14 
R15 


Adding features to existing 15.56F (may 
require new data blocks or growth of existing 
blocks when activated) 


R16 
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Optional package considerations for ST and option 21: Due to the large 
number of optional packages, you will not be able to run all optional 
packages on these systems. The number of optional packages you can 
equip depends on disk size. See Figure 18. 


Table 37 
Disk space calculations—ST and option 21 


Memory item 5.25 inch 3.5 inch space 
y space (records) (records) 
Space available on two disks 


Subtract basic software load 
(including overlays, etc.) 


Subtract packing factor* 


Space available for data and 
optional program store 


Subtract data store 


Space available for optional 
program store 


*Packing factor allows for the possibility of unusable space when disks are 
formatted to specific customer requirements. In the worst case, this is up to 80 
records. 





Software on 5.25 inch disks There is insufficient space on the disk to 
accommodate all the memory contents, therefore not all of memory can be 
utilized. 


All optional packages together require 423 kwords. There are only 85 kwords 
available on disk and 298.4 kwords in memory available for optional 
packages. Therefore, only 85 kwords are available for optional packages. 
More packages may be included if you are willing to sacrifice some of the 
space allocated for data store. 


Software on 3.5 inch disks There is more than enough space on the disk to 
accommodate a completely full memory, therefore the number of optional 
packages installed is only limited by memory size. 
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All optional packages together require 423 kwords. While there are 370 

kwords available on disk for optional packages, there are only 298.4 kwords 
in memory available for optional packages. (More packages may be included 
if you are willing to sacrifice some of the 64 kwords allocated for data store.) 


All Non-option 81/61C/51C systems have floppy disks. Two drives are 
provisioned on each system, called the A and B drives. Hard disks are 
optional, but are normally considered essential for larger systems. If a hard 
disk is provisioned, it is laid out identically and can perform the same 
functions as the floppy disk, except that the media is not removable. Once the 
data has been placed on the hard disk (via the EDD function of LD43) the user 
can choose whether to sysload from the hard disk or floppy by selecting the 
appropriate options in the Meridian 1 data base configuration record (LD17). 


Over the years, several vintages of floppy disk drives and media have been 
supported. Table 38 shows, for each type of drive, the physical dimensions, 
the size in records, the X11 release which introduced the drive, and the 
corresponding hard disk size at that release. 


Table 38 
Floppy disk drives 


Physical KByte Introductory Floppy Hard disk 
dimensions records X11 release MBytes MBytes 


1.1Mb 10Mb 
1.4Mb 20Mb 
2.8Mb 40Mb 





Note: This applies to options 51/61/71 only. On options 
51C/61C/81/81C, “4Mb” (2850 1 Kb record) 3.5” floppies are used. The 
hard disk is partitioned into a 30Mb unprotected partition and a 60Mb 
protected partition. The total hard disk size can range from 120Mb to 
300Mb, depending on when it was purchased. For more information, see 
“Mass Store on option 51C/61C/81/81C systems (NT6D66, NT9D19, 
and NT5D10 CP cards)” on page 128. 
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The hard disk total area (up to 40,000 1K byte records) greatly exceeds that 
provided by the set of floppies (2 or more floppies at 2850 1K byte records 
each). As a result, the hard disk size is not a constraining factor on system 
capacities. 


Disk Layout The layout of data on disks is the same, regardless of drive 
type. There can be multiple A disks (though there is usually only one) and one 
B disk. The A disks contain the package directory, the Meridian | program, 
most overlays, and an End of File (EOF) record. The B disk contains the 
Meridian | database, the hardware configuration record, firmware, the rest of 
the overlays, if any, and an EOF record. 


Omega floppy drives (all types) have slots for two disks, disk A and disk B. 


There can be multiple A disks and one B disk. The A disk contains the 
package directory, the Meridian 1 program, most overlays, and an End of File 
(EOF) record. The B disk contains the Meridian 1 database, the hardware 
configuration record, firmware, the rest of the overlays (if any), and an EOF 
record. 


The hard disk is laid out identically to the floppies, with the disk B contents 
following that of disk A. Overlays are stored in ascending order by overlay 
number. 


Sysload design requires that the entire database reside on one disk, disk B. 
SL-1 software may overflow onto a second disk. PSDL must reside on one 
disk—either the first A disk or the B disk. 


The layout of data on disks is the same, regardless of drive type. There can be 
multiple A disks (though there is usually only one) and one B disk. The A 
disks contain the package directory, the Meridian | program, most overlays, 
and an End of File (EOF) record. The B disk contains the Meridian 1 
database, the hardware configuration record, firmware, the rest of the 
overlays, if any, and an EOF record. 
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Figure 9 
Disk layouts and contents 


Sysload & Directory ~(10-20 records) | Configuration Record 1 record 


Rest of SL-1 Overlays ~(200—1,000 records) 
Firmware ~(2-10 records) 


SL-1 Overlays ~(200 up to1,800 records) 


Overflow to 2nd A disk, if necessary PSDL ~(900-2,100 records) 
(releases before 18 only) 


(Peripheral Software Download) 


SL-1 Resident SW ~(800up to 3,600 records) 


f 


Overflow to 2nd A disk, if necessary 
(for release 18 and beyond). 


User Database ~(300-—1,500 records) 


record| EOF 1 record 


553-0048 
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Disk space computations 


The three variable components of disk space are program store, office data, 
and Peripheral Software download (PSDL). Methods used to determine their 
mass storage requirements are described below. 


Program store The SL-1 program occupies space on the disks according to 
the following formula: 


number of disk records = sw x c xd 


where 
sw= overlay size + resident software size + firmware size in SL-1 
kwords 
= a disk storage overhead factor of 1.03 


c 
d = conversion factor from words to bytes, which varies by machine 
type, as shown in Table 39 


Table 39 
Number of Bytes per SL-1 word 


Option 21, ST Options 21E, 51, 61, 71, XT and NT 
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In the sw term, overlay and resident SL-1 program size are feature package 
dependent, as discussed in “Memory size” on page 89. Table 40 illustrate for 
supported releases Program Store record counts assuming all packages 
equipped. 





Table 40 
Program store disk capacity requirements (1 kB records) 


Resident : Overlay 
sw/fw sw 


Program Store = 
Release 


ST Option 21 NT/XT Option 51 Option 61/71 Option 21E 
1770 1880 
2390 2390 2555 2555 2555 
2975 2975 2975 2975 
3479 3479 3479 3479 
20A 5314 5314 3100* 
5406 5406 5406 


5876 5876 5876 


*Code was compressed to allow sysload from two floppies. At release 20A, not all 21E had hard 
disk drives. 


The Meridian 1 program occupies space on the A disks according to the 
following formula: 





# disk records = SW * c * d 


where SW = Overlay size + Resident size + Firmware size (in K 
words). These quantities are feature package dependent, 
as shown in the Memory section of this document. 


c= adisk storage overhead expansion factor, currently 1.03 
d= the conversion factor from words to bytes (see Table 41) 
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Table 41 
Word to byte conversion factors 


System option Conversion factor 


ST, STA, 21, 21A 
NT, XT, 51, 61, 71 





Office data Since the sysload program requires that the entire database and 
PSDL reside on a single floppy (Disk B), floppy size is a constraint when 
creating databases. Table 42 shows typical and maximum database sizes for 
the different machine types. 


Table 42 
Database sizes (1 kB records) 


Typical large Largest known 


Machine type database database 


ST/option 21/21A/21E 
RT/NT/option 51/61 





XT/option 71/81 


On an existing system, database size can be measured by performing an EDD 
in LD 17. After completing the EDD, the system will print the database size 
in number of records to the TTY port. 


There are two components to consider in estimating the database size for a 
new system—the size of the protected data store and the cell register space 
required. Use the procedure described in “Data store” on page 105 to estimate 
the protected data store size. Estimate call register space as follows: 
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Call Register Call register space (in 1kB records) = Number of call 
registers x Number of words per call register x Number of bytes per word + 
1,024 bytes/kB. 


Table 43 
Typically maximum number of call registers by machine type 


Number of call Number of call 
Machine Type registers registers 
(Typical) (Maximum) 


Option 11E 


Option 21E 
Option 51/61 
Option 71 





Table 44 
Number of words per call register by release 


Words per call register data 


Release block 





Now that you have computed the protected data space and call register space 
requirements (in 1kB records), compute the total data space requirement as 
follows: 


Data space required = protected data space + unprotected data space + 
(assume the same space requirement as for protected data space) + call 
register space. 
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Mass Store on option 51C/61C/81/81C systems (NT6D66, NT9D19, 
and NT5D10 CP cards) 

Software installation and SYSLOAD 

On the Thor machines, the SL-1 program is loaded to hard disk via an external 
medium and then SYSLOAD is performed from the hard disk. (Due to the 
need to accomodate a much larger and growing SL-1 program, this is a 
departure from the Omega machines, on which the floppies and the hard disk 
were interchangeable as means of uploading the SL-1 program and 
SYSLOAD could be performed from either.) At present the software 
uploading medium is either a stack of 8-16 4MB floppy disks, on systems 
purchased prior to Release 23, or a CD-ROM, on systems purchased from 
Release 23 on. The SL-1 customer database is loaded to the hard disk on a 
separate floppy, which can be rewritten via a “backup” operation or reread to 
hard disk via a “restore” operation (LD 43). 


The hard disk total capacity is a function of whatever is currently available 
from the manufacturers. At present, the disks being shipped with the 
Meridian 1 are 2GB. Whatever the total capacity, however, the actual storage 
capacity available to the Meridian 1 is determined by the disk partitioning 
into the protected and unprotected area. Since Release 21 this has been set at 
30MB for unprotected and 60MB for protected. 


Pre-Release 23 : IOP/CMDU 

Prior to Release 23, the software uploading medium was a 4MB disk drive. 
The SL-1 program was read in from a stack of 4MB floppies. (A stack of 8 in 
Release 18 and a stack of 16 by Release 23.) This is being replaced in Release 
23 by the introduction of the Input/Output Disk Unit with CD-ROM 
(IODU/C) card, which introduces a CD-ROM - floppy drive combination 
discussed in the next section. IODU/C preserves the architectural 
characteristics of the IOP/CMDU recognized by the rest of the system - the 
CP-IOP interface, and the Ethernet and SCSI capabilities of the IOP family. 


Release 23 : IODU/C 

By means of the IODU/C feature, Release 23 introduces software delivery by 
CD-ROM to Meridian 1 systems. IODU/C incorporates a Keycode based 
S/W installation and feature expansion methodology. Highlights of IODU/C 
include: 


e Software delivery via CD plus single install floppy. This replaces 
the (large) stack of floppies required to install software in the past. 


e Replacement of single 4MB floppy drive with a 2MB drive. 
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The IODU/C hardware replaces the old IOP/CMDU pack in the exact same 
three slots; ie., the old and the new are incompatible. In Release 23 IODU/C 
will be shipped with all new systems and all hardware upgrades. The 
IOP/CMDU is still supported on upgrades to Release 23 that involve software 
only. 


The following table provides the expected maximum floppy disk space 
required (before compression) by SL-1 databases for the supported option 
51C/61C/81/81C machine types. These are conservative but realistic 
estimates; that is, not all sites with the given machine type will have databases 
as large as shown. 


Table 45 
Floppy Disk Space Requirements Projection for SL-1 Customer Data 
(MB) 
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Hard disk layout The hard disk has a total capacity of at least 120 MB. See 
Table 48 for a description of disk capacities by X11 release. In addition to 
program and data storage, there is also a maintenance report database which 
provides logging capabilities. The hard disk is divided into two 
partitions—protected and unprotected. The protected partition uses 60MB (as 
of Release 21) and the unprotected partition uses 30 MB. 


Table 46 
Option 51C/61C/81/81C hard disk partitioning—Protected 


Protected Partition (MB) R20B 

SL_1 resident + overlay code 13.89 14.74 19.22 
PSDL 2.01 2.07 7.16 
OS code + data + tools 0.63 0.75 0.88 


Report database 0.80 0.88 0.97 


Language files 5.00 5.00 5.00 
Total 


Partition size 
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Table 47 
Option 51C/61C/81/81C hard disk partitioning—Unprotected 


Unprotected Partition (MB) 


SL_1 database (option 81 Pdata + backup) 2.87 3.37 
(NT6D66 CP card is shown prior to Release 

23, NT5D10 CP card is shown for Release 

23 as it is the biggest data user) 


Report log file 
HW infrastructure DB + backup 


Patches 


Microcell Mobility Data 


Total 
Partition size 


Hard Disk Capacity (MB) 
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Table 48 
History of hard disk sizes 


Space for Omega 


systems Thor partition size 


Manufactured capacity 


X11 


release Floppy 1kB Hard Protected/ 


size records disk MB ms Unprotected MB 
(floppy) 


“Hardware breakpoint for floppy and hard disk. Entirely new MSU. 
**In Release 23, new systems (IODU/C delivery) have 2MB floppies. 





On the option 81/61C/51C processor the hard disk and floppies are not 
interchangeable. The floppies perform a one-time upload of the Meridian 1 
program and data; then sysloads are performed from the hard disk. In addition 
to storing floppy contents, the hard disk is used for maintenance reports and 
other logging capabilities. As on the OMEGA processor, the database is 
confined to a single floppy, so that there is a potential constraint imposed by 
floppy size. The hard disk, at a minimum of 120 Mbytes of storage, is not a 
constraining factor at this time. 
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Floppy disk layout The number of floppies required to load the program 
(including the final data disk) has grown since the introduction of the Thor 
system, as follows. 


Table 49 
Number of program floppy disks (4MB) 


Release Number of floppy disks 





Release 23 software is shipped using the old CMDU / IOP floppy disk 
delivery system if the site is a software-only upgrade. Otherwise, software is 
shipped via CD-ROM in the new IODU/C delivery system. 


The database floppy has 2850 1 kB records, of which 5 are reserved for 
overhead. The remaining 2845 are available for database and patches. 


Table 50 
Floppy disk layout: 2850 records available 


Approximate number 
of records occupied 


SL-1 database overhead 3 


Hardware infrastructure database 2 


User database (largest presently known) 1725 


Patches use remaining space 
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Auxiliary processors 


Currently, auxiliary processors include Meridian MAX, Meridian Mail, 
Customer Controlled Routing, and Meridian 911. These all incorporate a 
155 MB tape drive and a hard disk (either 172 MB, 240 MB or 520 MB). The 
processor’s UNIX® Operating System is loaded to hard disk from one tape, 
and the application program and data from another. In addition to the 
operating system and application program and data, the hard disk also 
accommodates caching areas and third-party applications. 


Table 51 lists the various auxiliary processors and shows the sizes of the mass 
storage media for each. To see the available space on these media, see 


“Worksheets” on page 231. 


Table 51 
Mass storage media for the auxiliary processors 


System Applications Hard disk Commenis/ 


Product ae 
tape tape projections 


Meridian Link Module 155 MB 155 MB 172 MB These products all 
use the same system 

Customer Controlled 155 MB 155 MB 172 MB software. 

Routing 


911 Services 155 MB 155 MB 172 MB 


ACD Reporting System 155 MB 155 MB 172 MB Uses a subset of the 
MAX4 / MiniMAX available system 
software. 


ACD Reporting System 155 MB 155 MB 520 MB 
MAX5 


Interactive Voice Response 155 MB 155 MB 240 MB 





Refer to the following documents for information regarding the auxiliary 
processors: 


— Meridian MAX Installation (553-4001-111) 


Meridian Link/Customer Controlled Routing: 
— Meridian Link installation (553-3201-210) 
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